Uploaded image for project: 'ZABBIX FEATURE REQUESTS'
  2. ZBXNEXT-4863

Zabbix Configuration as a Code (ZCaasC)



    • Change Request
    • Status: Open
    • Trivial
    • Resolution: Unresolved
    • 4.2 (plan)
    • None
    • Frontend (F)
    • Frontend and API Zabbix


      Description: Develop a plugin or functionality to be made available in a submenu (under the Administration menu) where you can export and import the entire Zabbix configuration into YAML files [1] (YAML Is not Markup Language) or XML (Extensible Markup Language) [2].

      Motivation: Zabbix currently enables you to export and import XML files for some functionality (Maps, Screens, Templates, Hosts) and also allows interaction with the API to export/import all configuration. But this does not solve a problem: automating the configuration of a Zabbix server pool and manage configuration as a code. For each Zabbix server, there is a set of manual activities: such as user registration, SLA, customer business suitability, among others. This does not make it possible to scale productivity to an X number of servers, and the time to configure them is directly related to the number of people involved in the configuration, number of servers, expertise of the people involved, and configuration complexity to suit the business. Even if a Zabbix is configured for multiple clients, but there are settings that are common or can be reused for multiple clients.
      Advantages: With the implementation of this functionality, we can have the following advantages:
      • Increased productivity because you configure a Zabbix server and replicate/export/import/adapt the configuration to N servers in a short time.
      • Versioning of the Zabbix configuration file (Git/SVN).
      • Traceability and auditing of changes to the Zabbix configuration file allied to the configuration versioning tool (Git/SVN).
      • Backup of the file containing the entire configuration without the need for database backup (database backup is still required for the data, but the configuration can be replicated without necessarily backing up the associated database).
      • Readability and documentation of the configuration file (if the YAML standard is used, closer to the human being).
      • Standardize the configuration of a Zabbix server suite where possible (even with business specifics).
      • Sharing of the expertise used to configure a Zabbix (because the YAML standard, accepts comments to document and better explain why some configurations).
      • Provides work with more customers and Zabbix configuration projects in a shorter time frame than currently.
      • Consistency with DevOps and Agile cultures, configuration management (ITIL), and automation requirements.
      • Enables the Zabbix configuration to be managed as code rather than the basis for mouse clicks, as it is today.
      • Zabbix must export the hashed passwords (MD5 / SHA256 / SHA512) and not plain text in the configuration file;
      • Images registered in Zabbix can also be exported/imported in base64 in the configuration file;
      • Do the syntax handling of the configuration file;
      • Create documentation so that external plugins and services can fit the syntax to have the exported configuration as well;
      Projects that already use this idea: Jenkins [3] [4]

      Example of a file used by Jenkins. [5]
      By loading this configuration file, Jenkins not only reads the plugins settings but also installs the required plugins as they are quoted in the file. So you really know what you have and how it's set up at Jenkins. The idea would be to make this parallel in Zabbix.



        Issue Links



              vmurzins Valdis Murzins
              aeciopires Aecio Pires
              30 Vote for this issue
              26 Start watching this issue