Developing ZenPacks: Presented by Zenoss' Chet Luther (Principal Engineer) and Joseph Anderson (Senior Solutions Engineer)
Access the full presentation recordings for GalaxZ17 here: http://ow.ly/WyBu30cakk0
- Who Am I?
- bulk of career experience in availability and performance monitoring
- spent about 10 years in support and systems administration before becoming a developer
- understand need for immediate solutions while knowing that these solutions live longer than intended (hence need for good design)
- monitoring expertise requires generalist approach with multiple skillsets and need for flexibility
- need to rabidly become subject matter amateurs and change topics rapidly
- need to wrangle with monitoring targets more than wrangle with monitoring platform
- What is ZPL?
- part of ZenPack SDK (only part for now)
- Goals:
- reduce barrier to entry for new developers
- reduce development costs for existing developers
- reduce duplication of effort
- storehouse of best practices and techniques
- allow users and developers to focus on their problems, not Zenoss’ problems
- Abstract development pattern
- First design model (entity-relation diagram)
- define classes/class_relationships in YAML
- decide what to collect, how, and outline event conditions
- personal experience w/upkeep nearly 40 ZPs
- "devops" type role where development time was available only when everything else was OK
- had to overhaul all of them to make transition from 3.x to 4.x platform
- introduction of Zuul (routers, adapters, facades, interfaces, infos, etc)
- first effort took 6 months to a year
- after updating around 5 of these this became very repetitive
- also seemed to reqire "a lot of code" to acheive modest results.
- wrote ConstructionKit to collect known best practices and solutions and to streamline my work
- After becoming familiar with ZPL, I realized that they had common goals with different approaches.
- YAML is a superior method for generating specifications
- cleaner and easier to read
- abstraction should broaden ZP support across platform versions
- ZPL built with a deeper expertise and understanding of platform than I had at the time when developing ConstructionKit
- Reduce need for a masters in Zope, with a minor in Zuul, Javascript, and TALES
- You are rarely appreciated for the issues you prevented
- You can be sure your gaps will be highlighted, especially if doing so covers someone else’s oversight.
Awareness of the need for monitoring usually follows production deployment, meaning you’re behind at the outset.
Major changes occur within your organization with inadequate awareness or consideration of consequences.
- How do we use ZPL?
- Current ZPL 2
- Microsoft Windows 2.7.0
- EMCXtremeIO
- Migrating from ZPL 1.x
- HP
- IBM Power
- Linux
- vSphere
- AIX
- HPUX
- Current "legacy" ZPs will be migrated to ZPL as part of ongoing development
- approximately 70-75% reduction in code.
- How do we use ZPL?
- Current ZPL 2
- Microsoft Windows 2.7.0
- EMCXtremeIO
- Migrating from ZPL 1.x
- HP
- IBM Power
- Linux
- vSphere
- AIX
- HPUX
- Current "legacy" ZPs will be migrated to ZPL as part of ongoing development
- What's new in ZPL 2.0?
- Approximately 40 (documented) bug fixes
- Approximately 30 features
- Major Features
- Centralization
- should reduce nubmer of hotfix releases (since many simply updated the zenpacklib.py)
- increase predictability and consistency of capabilities and presentation between ZenPacks
- future improvements leveraged across dependent zenpacks without need for per-zenpack updates
- reduce development time for new features and new ZPs
- simplify zenpack creation
- can call zenpacklib from /opt/zenoss/bin
- ZPL has stabilized and matured to the point that advantages of centralization outweigh disadvantages
- bug fixes inherited by dependencies
- performance improvements also shared
- built-in capabilities reduce need for dependent customization and legacy upkeep
- Performance
- optimized YAML load times
- one drawback of dynamically generated classes (zpl) is increased daemon startup times due to interpretation overhead
- startup time = (normal startup) + sum (per ZP YAML load)
- reduce daemon (zenbinary) startup time/cost
- high complexity cases reduced from up to 9 seconds (per zenpack) to 1-2s
- typical case of simple to medium complexity .1-.5s
- grid display of metrics in 5.x
- Logging
- Verbosity configurable per-ZenPack
- Class overrides can use self.LOG
- New object types
- Proxy classes
- Base ZenModel classes now available for use
- includes properties, relations, and methods
- Event Classes
- Process Classes
- Inheritance improvements
- Improved predictability/intuitive behavior of property/relation inheritance
- Unit testing
- drastically expanded scope
- approximately 70 tests at present
- improve reliability and predictability for dependent ZPs
- Centralization
- ZPL has stabilized and matured to the point that advantages of centralization outweigh disadvantages
- bug fixes inherited by dependencies
- performance improvements also shared
- built-in capabilities reduce need for dependent customization and legacy upkeep
- should reduce nubmer of hotfix releases (since many simply updated the zenpacklib.py)
- increase predictability and consistency of capabilities and presentation between ZenPacks
- future improvements leveraged across dependent zenpacks without need for per-zenpack updates
- reduce development time for new features and new ZPs
- simplify zenpack creation
- can call zenpacklib from /opt/zenoss/bin
- Performance
- optimized YAML load times
- one drawback of dynamically generated classes (zpl) is increased daemon startup times due to interpretation overhead
- startup time = (normal startup) + sum (per ZP YAML load)
- reduce daemon (zenbinary) startup time/cost
- high complexity cases reduced from up to 9 seconds (per zenpack) to 1-2s
- typical case of simple to medium complexity .1-.5s
- grid display of metrics in 5.x
- Logging
- Verbosity configurable per-ZenPack
- Class overrides can use self.LOG
- New object types
- Proxy classes
- Base ZenModel classes now available for use
- includes properties, relations, and methods
- Event Classes
- Process Classes
- Inheritance improvements
- Improved predictability/intuitive behavior of property/relation inheritance
- Unit testing
- drastically expanded scope
- approximately 70 tests at present
- improve reliability and predictability for dependent ZPs
- Centralization
- ZPL has stabilized and matured to the point that advantages of centralization outweigh disadvantages
- bug fixes inherited by dependencies
- performance improvements also shared
- built-in capabilities reduce need for dependent customization and legacy upkeep
- should reduce nubmer of hotfix releases (since many simply updated the zenpacklib.py)
- increase predictability and consistency of capabilities and presentation between ZenPacks
- future improvements leveraged across dependent zenpacks without need for per-zenpack updates
- reduce development time for new features and new ZPs
- simplify zenpack creation
- can call zenpacklib from /opt/zenoss/bin
- Performance
- optimized YAML load times
- one drawback of dynamically generated classes (zpl) is increased daemon startup times due to interpretation overhead
- startup time = (normal startup) + sum (per ZP YAML load)
- reduce daemon (zenbinary) startup time/cost
- high complexity cases reduced from up to 9 seconds (per zenpack) to 1-2s
- typical case of simple to medium complexity .1-.5s
- grid display of metrics in 5.x
- Logging
- Verbosity configurable per-ZenPack
- Class overrides can use self.LOG
- New object types
- Proxy classes
- Base ZenModel classes now available for use
- includes properties, relations, and methods
- Event Classes
- Process Classes
- Inheritance improvements
- Improved predictability/intuitive behavior of property/relation inheritance
- Unit testing
- drastically expanded scope
- approximately 70 tests at present
- improve reliability and predictability for dependent ZPs
- Centralization
- ZPL has stabilized and matured to the point that advantages of centralization outweigh disadvantages
- bug fixes inherited by dependencies
- performance improvements also shared
- built-in capabilities reduce need for dependent customization and legacy upkeep
- should reduce nubmer of hotfix releases (since many simply updated the zenpacklib.py)
- increase predictability and consistency of capabilities and presentation between ZenPacks
- future improvements leveraged across dependent zenpacks without need for per-zenpack updates
- reduce development time for new features and new ZPs
- simplify zenpack creation
- can call zenpacklib from /opt/zenoss/bin
- Performance
- optimized YAML load times
- one drawback of dynamically generated classes (zpl) is increased daemon startup times due to interpretation overhead
- startup time = (normal startup) + sum (per ZP YAML load)
- reduce daemon (zenbinary) startup time/cost
- high complexity cases reduced from up to 9 seconds (per zenpack) to 1-2s
- typical case of simple to medium complexity .1-.5s
- grid display of metrics in 5.x
- Logging
- Verbosity configurable per-ZenPack
- Class overrides can use self.LOG
- New object types
- Proxy classes
- Base ZenModel classes now available for use
- includes properties, relations, and methods
- Event Classes
- Process Classes
- Inheritance improvements
- Improved predictability/intuitive behavior of property/relation inheritance
- Unit testing
- drastically expanded scope
- approximately 70 tests at present
- improve reliability and predictability for dependent ZPs
- Logging
- Verbosity configurable per-ZenPack
- Class overrides can use self.LOG
- Inheritance improvements
- Improved predictability/intuitive behavior of property/relation inheritance
- Unit testing
- drastically expanded scope
- approximately 70 tests at present
- improve reliability and predictability for dependent ZPs
Zenpacklib arguments:
Lint
Optimize
Diagram
Paths
Dump-templates
Dump-event-classes
Dump-process-classes