Icinga Camp New York 2018 - What's evolving in icinga 2018
•
1 like•979 views
Over the last couple of years many things have changed in the Icinga universe. From introducing new features and components to integrating a variety of other tools of your monitoring stack.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Icinga Camp New York 2018 - What's evolving in icinga 2018
Similar to Icinga Camp New York 2018 - What's evolving in icinga 2018 (20)
More from Icinga
More from Icinga (20)
Recently uploaded
Recently uploaded (20)
Icinga Camp New York 2018 - What's evolving in icinga 2018
- 1. What‘s Evolving in Icinga #icingacamp | March 16th, 2018 | New York
- 2. Introduction
- 3. Introduction •Eric Lippmann •CTO @icinga •Senior Lead Developer @netways
- 5. Icinga 2 Notification Configuration
- 6. Notifications Icinga 2 Notification Configuration •Users •User groups •Time periods •Escalations •Scripts
- 7. Notifications Icinga 2 Notification Configuration •Can’t manage on-call scheduling •Users can’t subscribe to events on their own •Everything is Icinga 2 config •Hard to split up configuration across teams
- 8. Notification Manager - NoMa
- 9. Notification Manager •Icinga Web 2 Module •Central component to manage, send and track events, incidents and notifications
- 10. Notification Manager •Configuration via GUI •Permissions and restrictions •On-call scheduling
- 11. Events
- 12. Notification Manager Events •Where does it come from? •What is affected? •When was it triggered? •What’s the severity? •What’s the message?
- 13. Notification Manager Events •Icinga check results are events •It’s possible handle any other event in NoMa too
- 14. Notification Manager Events •Events are submitted via CLI, API or by manually inserting them into the NoMa database
- 15. Notification Manager Events •Events are reaped periodically by the NoMa daemon
- 16. Incidents
- 17. Notification Manager Incidents •Incidents are created from problem events •Paused and resumed from events •Closed and resolved from events
- 18. Notification Manager Incidents •Incidents are escalated according their assigned policies •Policies are reuseable escalation rules for incidents
- 19. Architecture
- 20. Architecture •MySQL database •NoMa daemon as CLI command •GUI for configuration and overviews
- 21. Architecture •NoMa daemon sends alerts to contacts, contact groups and /or schedules •State of an escalation saved to database •Default channels are mail, sms and voice
- 22. Architecture •Contacts, contact groups, schedules, time periods, overrides, holidays, policies, channels manageable via GUI
- 23. Architechture •Route events to policies based on filters •Notification aggregation •„My notification channels“
- 28. Mobile Experience •Push notifications •Optimized workflows •Mobile optimized UX
- 29. Icinga App for iOS and Android
- 30. Mobile Experience Icinga App •React Native •Based on React •JavaScript
- 31. Mobile Experience Icinga App •Like a “native“ APP •Native UI elements •Live/hot reloading for devs •Cross-platform
- 32. Mobile Experience Icinga App •Icinga Web 2 API client •Permissions and restrictions •Notification configuration
- 33. Mobile Experience Icinga App •Monitoring views, e.g. hosts, services, groups •Monitoring actions, e.g. acknowledge, reschedule, schedule downtime •Multiselect
- 34. Icinga App Architecture Icinga Web 2 API Icinga 2 Icinga App DB
- 35. Icinga App Architecture Icinga Web 2 API Icinga 2 Icinga App Cloud Messaging DB
- 40. Reporting
- 41. Reporting •Very important part of monitoring •No reporting related functionality in Web 2, yet •Big missing feature
- 42. Reporting •JasperReports for Icinga 1.x •Discontinued •Depencies add complexity
- 43. Reporting External Reporting Engine •Learn how the tool works •Define how to fetch data •Define how the report should look like •Markup / templating language exclusive to the tool
- 44. Reporting •Web 2 knows how to fetch data •Reporting is just another presentation layer •No external engine needed
- 45. Icinga Web 2 Reporting Module
- 46. Reporting Icinga Web 2 Reporting Module •Central component for reporting related functionality •Ad-hoc and scheduled generation of reports •Simple, easy to use yet flexible and powerful
- 47. Reporting Icinga Web 2 Reporting Module •Just a framework •Reporting engine •GUI for configuration
- 48. Reporting Icinga Web 2 Reporting Module •Reasonable defaults •Time periods •Filter
- 49. Reporting Icinga Web 2 Reporting Module •Introduces hooks •Other modules provide formatted data for reports
- 51. Icinga Web 2 Reporting Module Reporting Widgets •General overviews •Availability •Downtimes, Notifactions
- 52. Icinga Web 2 Reporting Module Reporting Widgets •State history •SLA •Top X
- 53. Icinga Web 2 Reporting Module Reporting Widgets •Logs •Graphs •Director activities and deployments
- 59. Reporting Icinga Web 2 Reporting Module •Widgets provided by modules •Just HTML •Plug widgets together to create your very own report
- 60. Reporting Icinga Web 2 Reporting Module •Custom covers, headers, footers and logos •Add pages from other sources •Saved and reused as report templates •Default template with the Icinga design
- 61. Reporting Icinga Web 2 Reporting Module •Permissions and restrictions •Permissions to create, edit and view reports •Limit which sources and reports should be accessible
- 62. Icinga Web2 Reporting Module Configuration •Name of the report •Widgets •Schedule for automatic generation and distribution
- 63. Icinga Web2 Reporting Module Configuration •Recipients •„Security Context“ •Output format
- 64. Icinga Web2 Reporting Module Output Formats •Preview in HTML •JSON, CSV •HTML to PDF
- 65. Icinga Web2 Reporting Module PDF •PHP library dompdf •Bugs with the layout •Problems with icons, images and large tables •It takes quite long to generate a PDF •Alternatives?
- 67. Long Live Chromium Headless
- 68. Icinga Web 2 Reporting Module Chromium Headless •First tests are quite promising •Not sure how to bundle it yet •Is it available for every platform?
- 74. IDO
- 75. IDO State of Things •Good •Seperation of status, config and history
- 76. IDO State of Things •Not so good •Single „ID“ table for every object type •Relies on auto increment keys •UTF-8 support •Custom var blobs
- 77. IDO State of Things •We constantly improved the data backend •There are things we can‘t fix without breaking too much backwards compatibility
- 78. IDO State of Things •Loads of write operations •Configuration has to be written synchronously and must be written before status information
- 79. IDO State of Things •Many expensive JOINs necessary •Can’t deal with split brain scenarios •History clustered over several tables
- 80. We need a new database schema
- 81. „IcingaDB“
- 82. IcingaDB •Config •Few changes, many tables involved •Status •Loads of write operations •History •Needs to be rotated or archived
- 83. IcingaDB •Parallel operations •Asynchronous operations •Write without having to read
- 84. IcingaDB •Save JOINs •Split brain must not be an issue •History, reporting, SLA
- 86. IcingaDB •1.000.000 checks per minute • 16.667 checks per second
- 87. IcingaDB •Separate status data from volatile information
- 88. IcingaDB Status Data •Relevant for history •State changes •Acknowledgements •Downtimes
- 89. IcingaDB Volatile Information •Not relevant for history •Check results which don‘t change state •Obsolete once a new check result arrives
- 90. IcingaDB •Database: Status data •Redis: Volatile information
- 91. IcingaDB •IcingaDB as new feature in Icinga 2 •New monitoring module for Icinga Web 2 •IDO will still be supported
- 92. RECAP •NoMa, Icinga App •IcingaDB, Reporting •Give us feedback •Enjoy some drinks with us