Developing ZenPacks the Right Way: Introducing the SDK
•Download as PPTX, PDF•
0 likes•221 views
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
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Developing ZenPacks the Right Way: Introducing the SDK
Similar to Developing ZenPacks the Right Way: Introducing the SDK (20)
More from Zenoss
More from Zenoss (20)
Recently uploaded
Recently uploaded (20)
Developing ZenPacks the Right Way: Introducing the SDK
- 1. ZenPackLib 2.0 Joseph Anderson / Zenoss Solutions Engineering
- 2. Who Am I? • Believes that “temporary fixes” often become the norm, hence the need for well-designed solutions • Believes that good monitoring is a means to improving the business and not an end in itself janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 2 • IT career spent in availability and performance monitoring • Generalist • Subject Matter Amateur
- 4. janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 4 ZenPack SDK • Reduce barriers to entry • Reduce legacy upkeep • Demonstrate best practices • Encourage focus on problem domain
- 6. Why do I use ZenPackLib? • In my previous position I wrote and maintained around 40 ZenPacks (most are community) • Migrating these to Zenoss 4.x was painful • Developed ConstructionKit ZP (community) to make this easier • Doing so made it possible • ZenPackLib has several advantages over ConstructionKit, and now has most of its capabilities janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 6
- 7. Why should you use ZenPackLib? • You have more important things to do • You need things done quickly • You need flexibility • You hate gaps in your monitoring coverage • You need your monitoring system to be able to accommodate rapid changes in your environment janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 7 0 100 200 300 400 500 600 PRE-ZPL POST-ZPL LEVEL OF GOODNESS
- 8. How does Zenoss use ZenPackLib • Now used extensively across most of our ZenPacks • 1.0 • HP Proliant • IBM Power • LinuxMonitor • vSphere • HyperV • BigIpMonitor • Many others • 2.0 • Microsoft Windows 2.7.0 • EMC Base • Migration to ZenPackLib is now occurring in tandem with current development efforts janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 8
- 9. Migrating vSphere to ZenPackLib • 30% Code Reduction: • 8000 lines Python • 5800 lines XML • 2200 lines Javascript • 1200 lines YAML janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 9
- 10. What’s new in ZenPackLib 2.0?
- 11. A LOT! janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 11
- 12. ZenPackLib 2.0 • Approximately 40 defects resolved • Approximately 30 features added • Major themes • Centralization • Performance • Logging • ZenModel Proxies • Event Classes, Process Classes • Inheritance • Unit Testing • https://zenpack-sdk.zenoss.com/en/latest/ janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 12
- 13. Centralization • New capabilities provided • Performance improvements shared • Defect fixes inherited • Reduced downtime by reduction in need for ZenPack releases • Improved consistency, stability, and coherence between different ZenPacks janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 13
- 14. Performance • Optimized YAML load times • Factors into every daemon startup time • Summed across all installed ZPL-based ZenPacks • Worst case average of 8-9s reduced to 1-2s • Average use case .1-.5s • Grid display of metrics in 5.x janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 14
- 15. Capabilities • Proxy Classes • Most platform classes available for use as base class • Event Classes • Process Classes janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 15
- 16. Other Changes • Multiple YAML file support, directory loading • Logging • Inheritance Behavior • Improved detection of and automatic backups for template customizations • Dramatically expanded scope for unit testing • Callable from /opt/zenoss/bin • zenpacklib --help as the zenoss user janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 16
- 17. How do I get started?
- 18. Easily zenpacklib --create ZenPacks.NAMESPACE.ZENPACKNAME • Edit ZenPacks/NAMESPACE/ZENPACKNAME/zenpack.yaml • https://zenpack-sdk.zenoss.com/en/latest/ • Example ZenPackLibDemo: • https://github.com/zenoss/ZenPacks.zenoss.ZenPackLibDemo • Plan to update with more examples of common use patterns janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 18
- 19. How do I migrate from zenpacklib.py (1.0)?
- 20. Easily • Update __init__.py in your ZenPack’s root folder to contain: • If currently importing any method or class directly from zenpacklib.py, the path and possibly the use of the class or method will need to be revised janderson@zenoss.com © 2016 All Rights Reserved CONFIDENTIAL 20
- 21. Questions?
Editor's Notes
- - 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