- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
After you plan your Datadog installation design and best practices, concentrate on the construction of Datadog itself, understanding what needs to be installed, and the best way to achieve that.
As your IT footprint grows, you need to establish standards for software installation and usage. To do this, it’s important to develop precise, repeatable steps for reliably configuring software while maintaining the flexibility you need. This section explains how Datadog can efficiently integrate with these standards.
In the plan section, you explored a range of topics within a Datadog design specification. Ideally, every one of those questions would be fully researched and answered before executing a large rollout. However, enterprise IT engineering often requires you to pause and adapt as you build out your installation.
It is possible to stagger the installation of Datadog, and build up the complexity gradually. Some things must be done early, and others can wait. The following describes a breakdown of how you can apply primary (needs) versus secondary (wants) as you scale your Datadog installation.
Primary:
service:test
env:prod
version:1.x
Secondary:
As the owner of your Datadog platform, you will likely need to create a way for your users to consume your installation. There might be a wiki, ServiceNow integration, or Jira board that will publish Datadog, and provide a way to request them. This is the guide that your internal customers will use to deploy Datadog on the apps and infrastructure they manage.
The shape of this system will be different depending on your environment, but there are a few fundamental things that can accelerate this creation:
Build a list of Datadog installation tasks such as:
Gathering the minimum information sets can include things such as:
These definitions build upon the foundations of the architectural plan completed in the plan phase. However, if you are struggling with any of these definitions, Datadog has developed mechanisms to assist this management, outlined below.
Datadog is a RESTful API Platform that is fully documented and open. Most things you see in the UI can be built out programmatically. Datadog welcomes and fully supports the use of the API, even as a data source for your own custom applications.
All the objects you create in Datadog, such as the dashboards, alerts, notebooks, parsed logs, and configurations for cloud integrations are stored in the platform as JSON. They are exportable and importable. This opens a host of administration capabilities, including Full Infrastructure as Code (IaC) compliance, configuration backup, account migration, and reusability. Datadog also supports a Terraform Provider, and a CLI Tool for these purposes.
Provisioning is central to any enterprise IT environment. To manage Datadog at scale, integrate it into your provisioning process. The Datadog Agent’s simple installation model offers various ways to achieve this.
Like most enterprise software products, Datadog installations can be broken into three separate operations, each a part of the modular architecture referred to as the file/package/service model.
File(s): Contains configurations
Package: Holds binaries and controls their deployment
Service: Manages the runtime instance via the OS service system
The basic operations you must complete in order to install Datadog are the following:
File: Source code control can be used to store and control the edits of configuration files. Templating and IaC solutions like Jinja2 and Ansible are also highly effective.
Package: Use internal package repositories such as Artifactory or Nexus to host .rpm, .msi, and containerized Agent packages.
Service: Use of IaC, or shell scripting.
IaC: Infrastructure-As-Code has advanced in both sophistication and robustness. While it is almost universally used in cloud infrastructures, it is often retrofitted to long-established on-premise infrastructures. Its simple file/package/service structure has been leveraged to deploy significant Datadog footprints with IaC “tools” as rudimentary as a bash script. While this is not recommended, it stands as encouragement to begin the IaC adoption of Datadog as soon as possible, and when you do, you will find Datadog at the ready with sample code and integrations for Ansible, Puppet, Chef, Powershell, Bash, CloudFormations, Terraform, and more.
Recommendations:
When it comes to deploying Datadog Agent software, it is advisable to reuse as much of your existing provisioning systems as possible. Datadog software design is flat and compliant to industry standard methods.
Datadog’s Agent design is flat so that it can easily fit into any existing provisioning system. Use your existing capabilities for file/package/service, and incorporate Datadog into them. While the platform offers helpful mechanisms, your local conditions determine the best method for any given situation.
Review the Datadog administrator’s run documentation to outline a maintenance schedule, perform Datadog Agent upgrades, build out Dashboards, and ensure your Datadog installation remains healthy.
추가 유용한 문서, 링크 및 기사: