We’ve made the latest version of our implementation of the OpAMP specification available. It has taken longer to ready than the previous versions, but there is a lot been included, both in the core functionality, but also capabilities supporting the use and setup. Here are the headlines…

• The project has its own organization now (https://github.com/orgs/opamp-observe/) as mentioned here, but also a domain of https://opamp.info/ which will bounce you to the GitHub pages.
• Automated regression from clean to deployed and running a series of end-to-end tests as well as producing a guaranteed fresh set of artefacts has been implemented. This can be run against AWS (currently in use) or Azure (needs refining). These are triggered on changes to the main branch.
• GitHub pages with links all the documentation are established now.
• The Python wheel release artefacts are no incorporated into the release assets.
• The configuration for the Open Source Observability Day conference demo is available in the https://github.com/opamp-observe/demo-repository repo.
• We’ve added support for a couple more open-source observability tools:
  • Vector
  • Elastic Agent
  • Elastic Heart beat
• The client/consumer side has been refactored so it is easy to build your own observability agent controls and independently deploy them (not supported by the config editor).
• The CLI has been enhanced so it can help quickly spin up more advanced configurations – helpful for demos and real deployments.
• The Dev CLI has been improved.
• The server side now has a basic client side (Supervisor/Observer) configuration editor UI. Which can be deployed as a plugin.
• Improvements around the use of Podman and Docker for the containerization.

What next?

We’ve added to the documentation pages for the roadmap, initially we’re working to fill out the regression test sets at the moment. Other possibilities:

• Expand the client types
• Extend the client types to exploit more features.

Perhaps the most interesting idea, we’re thinking about is can we exploit tools like Netdata to discover what solutions are deployed and generate a requirements/configuration definition which can be used to generate a suitable agent configuration file.