What developers can really contribute in DevOps concept?
•Download as PPTX, PDF•
0 likes•85 views
This document provides an overview of how developers can contribute to DevOps practices through monitoring applications with Nagios. It discusses using the check_jmx4perl Nagios plugin to monitor Java applications by accessing metrics exposed via JMX, and implementing automatic configuration of monitoring checks using Puppet resources like exec, file, and nagios plugins. The document aims to demonstrate an end-to-end workflow of defining monitoring parameters, exposing them in JMX, adding the Jolokia agent, configuring Nagios checks, deploying the application, and automating monitoring setup with Puppet.
![About me
{
“First name”: “Taras”,
“Last name”: “Slipets”,
“E-mail”: “taras.slipets@gmail.com”,
“LinkedIn Profile”: “http://www.linkedin.com/
pub/taras-slipets/
48/466/516”,
“Interests”: [
“Software Engineering”,
“Music”
]
}
2](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to What developers can really contribute in DevOps concept?
Similar to What developers can really contribute in DevOps concept? (20)
More from Taras Slipets
More from Taras Slipets (13)
Recently uploaded
Recently uploaded (20)
What developers can really contribute in DevOps concept?
- 1. Helping hand to Ops or What developers can really contribute in DevOps concept? 1
- 2. About me { “First name”: “Taras”, “Last name”: “Slipets”, “E-mail”: “taras.slipets@gmail.com”, “LinkedIn Profile”: “http://www.linkedin.com/ pub/taras-slipets/ 48/466/516”, “Interests”: [ “Software Engineering”, “Music” ] } 2
- 5. Software engineering required Jedi skills… 5
- 6. so… 6
- 8. It’s with no doubt… 8
- 9. but… 9
- 10. 10
- 11. 11
- 12. 12
- 13. 13
- 14. 14
- 15. How do you know that everything is ok? 15
- 16. Why just not JMX? 16
- 17. Why just not JMX? 17
- 18. Scalability 18
- 19. Not only Java 19
- 21. 21 The secret you should know… How to achieve that, Master?
- 22. Monitoring 22
- 23. 23
- 24. Core features • Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.) • Monitoring of host resources (processor load, disk usage, etc.) • Simple plugin design that allows users to easily develop their own service checks • Parallelized service checks • Ability to define network host hierarchy using "parent" hosts, allowing detection of and distinction between hosts that are down and those that are unreachable • Contact notifications when service or host problems occur and get resolved (via email, pager, or user-defined method) • Ability to define event handlers to be run during service or host events for proactive problem resolution • Automatic log file rotation • Support for implementing redundant monitoring hosts • Web interface for viewing current network status, notification and problem history, log file, etc. 24
- 25. Configuration 25
- 26. Object Definitions • Host definitions • Host group definitions • Service definitions • Service group definitions • Contact definitions • Contact group definitions • Time period definitions • Command definitions • … 26
- 27. Nagios plugins • HTTP, POP3, IMAP, FTP, SSH, DHCP • CPU Load, Disk Usage, Memory Usage, Current Users • Unix/Linux, Windows, and Netware Servers • Routers and Switches • … • Java applications • … 27
- 30. 30 Welcome…
- 31. check_jmx4perl plugin Nagios plugin for monitoring Java applications. It uses an agent based approach for accessing JMX exposed information remotely. (Official documentation) 31
- 32. 32
- 33. Agent mode 33
- 34. Proxy Mode 34
- 37. Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to orchestration and reporting 37
- 38. Resource is our all • A user account • A specific file • A directory of files • A software package • A running service • A scheduled cron job • An invocation of a shell command, when certain conditions are met • … 38
- 39. Resources for us • exec • file • nagios_* 39
- 40. Anatomy of a Resource. Manifest 40 • Type • Title • Attributes • Values
- 41. How it goes 41
- 42. Putting all together 42 • Define monitoring parameters • Expose them via JMX mechanism • Add Jolokia facet to app • Enable check_jmx4perl plugin in Nagios • Write Nagios checks • Deploy • … • Be happy and have some beer with your team
- 43. Into the code 43
- 44. Links • Nagios • check_jmx4perl • Jolokia • Puppet 44
- 45. 45
Editor's Notes
- But now SD is 99% team work
- But now SD is 99% team work
- WHAT WE NEED?
- We need centralized solution
- Main Configuration File The main configuration file contains a number of directives that affect how the Nagios daemon operates. This config file is read by both the Nagios daemon and the CGIs. This is where you're going to want to get started in your configuration adventures. Documentation for the main configuration file can be found here. Resource File(s) Resource files can be used to store user-defined macros. The main point of having resource files is to use them to store sensitive configuration information (like passwords), without making them available to the CGIs. You can specify one or more optional resource files by using the resource_file directive in your main configuration file. Object Definition Files Object definition files are used to define hosts, services, hostgroups, contacts, contactgroups, commands, etc. This is where you define all the things you want monitor and how you want to monitor them. You can specify one or more object definition files by using the cfg_file and/or cfg_dir directives in your main configuration file. An introduction to object definitions, and how they relate to each other, can be found here. CGI Configuration File The CGI configuration file contains a number of directives that affect the operation of the CGIs. It also contains a reference the main configuration file, so the CGIs know how you've configured Nagios and where your object defintions are stored.
- Which plugin?
- Jolokia is a JMX-HTTP bridge giving an alternative to JSR-160 connectors. It is an agent based approach with support for many platforms. In addition to basic JMX operations it enhances JMX remoting with unique features like bulk requests and fine grained security policies.
- The agent exports on the frontside a JSON based protocol over HTTP that gets bridged to invocation of local JMX MBeans. It lives outside the JSR-160 space and hence requires a different setup. Various techniques are available for exporting its protocol via HTTP. The most prominent being to put the agent into a servlet container.
- Most of the time this happens for political reasons, where it is simply not allowed to deploy an extra piece of software or where doing so requires a lengthy approval process. Another reason could be that the target server already exports JMX via JSR-160 and you want to avoid the extra step of deploying the agent.
- This syntax is called a resource declaration. In Puppet, every resource is an instance of a resource type and is identified by a title; it has a number of attributes (which are defined by the type), and each attribute has a value.
- Manifests don’t get used directly when Puppet syncs resources. Instead, the flow of a Puppet run goes a little like this… Before being applied, manifests get compiled into a document called a “catalog,” which only contains resources and hints about the order to sync them in.