BK-CMDB Documentation

repository·master·Indexed 26 days ago

https://github.com/tencentblueking/bk-cmdb

An enterprise-grade Configuration Management Database (CMDB) for managing assets and applications. This documentation covers Kubernetes deployment via Helm charts, API Gateway (apigw) and ESB interface mappings, MongoDB database collection classifications, and core service configuration using environment variables for MongoDB, Redis, and authentication.

Tokens
331.6K
Snippets
668
Records
1.4K
Agent score
88%

What's inside BK-CMDB

  1. Overview of CMDB Sync Service

    master

    The CMDB Sync Service synchronizes CMDB data from a source environment (src) to a target environment (dest).

    Supported Resource Types:

    • biz (business)
    • set (cluster)
    • module (module)
    • host (host)
    • host_relation (host relation)
    • object_instance (model instance)
    • inst_asst (instance association)
    • service_instance (service instance)
    • process (process)
    • process_relation (process relation)
    • quoted_instance (table field instance)

    Sync Workflow:

    1. The source environment pulls data (full or incremental) and sends it to a transfer medium via an agreed protocol.
    2. The transfer medium moves the data to the target environment.
    3. The target environment's sync service reads the data from the medium and writes it to the target CMDB.
  2. Overview of Golang Metric SDK

    master

    The Metric SDK provides a flexible, pluggable runtime metric export service for components within the BCS ecosystem. It exposes metrics via an HTTP service and supports two types of key-value metrics: numeric (all exported as float64 for consistency) and string.

    Key features include:

    • Runtime Metrics: Automatically provides default Golang runtime metrics (CPU, goroutines, memory, etc.).
    • Non-intrusive & Non-blocking: Uses callback functions for data collection to decouple the SDK from the host component. To prevent a single metric from blocking the entire service, a default timeout of 5s is applied to each metric collection attempt.
    • Grouping & Labeling: Supports metric grouping for organized management and Labels (key-value pairs) for instance-specific identification (e.g., distinguishing between different clusters or regions like set: shenzhen).
    • Language Support: Currently supports golang only.
  3. Overview of BlueKing CMDB

    master

    BlueKing CMDB (Configuration Management Database) is an enterprise-grade configuration management platform designed for managing assets and applications. It features a customizable model management system that allows users to extend built-in models or create new ones for networks, middleware, and virtual resources.

    Key technical capabilities include:

    • Resource-centric architecture: Manages atomic resources categorized into Hosts, Processes, and General Objects.
    • Topology-based Host Management: Includes host attributes, snapshots, and ownership relationships.
    • Model Management: Supports built-in models (Business, Cluster, Host) and custom models.
    • Event System: Provides event registration and push capabilities via callbacks.
    • Permission & Audit: Flexible group-based permission management and user operation auditing.
  4. Overview of Business Topology Cache

    master

    The Business Topology Cache package provides a high-performance caching mechanism for business topologies, spanning from root nodes down to the lowest node modules. It is designed for scenarios requiring frequent topology lookups where performance is critical, such as job scheduled tasks.

    Key features include:

    • Brief Topology Representation: The cache stores a lightweight version of the topology containing only essential information: the object, instance ID, and name.
    • Event-Driven Refresh: The cache is automatically refreshed when topology changes occur (e.g., adding/removing custom level instances, sets, or modules).
    • TTL (Time-To-Live): A TTL of several hours is applied to automatically clean up cache entries when a business is deleted or archived.
    • Safety Refresh Mechanism: To ensure data consistency, the cache is refreshed every 15 minutes regardless of whether events have occurred.
    • Database Fallback: If a business topology is not found in the cache, the system falls back to reading directly from the database.
  5. Overview of BK-CMDB Architecture

    master

    BlueKing CMDB (BK-CMDB) is an enterprise-grade configuration management platform for assets and applications. When deploying on Kubernetes, the system is split into two primary components:

    1. Backend Service: Provides the core API functionality.
    2. Web Service: Provides the user interface and interacts with the backend via the apiserver.

    Deployment Order Requirement: You must deploy the backend service first. Wait for the backend service to be fully started and healthy before proceeding to deploy the web service.

  6. Overview of CMDB EventServer

    master

    The CMDB EventServer is a module designed for event subscription and notification. It supports two primary interaction patterns:

    1. Callback-based: Event subscription and pushing via callbacks.
    2. Watch-based: Event listening using a Watch pattern.

    It acts as a bridge between the resource control layer (CoreService) and subscribers, ensuring data changes are propagated efficiently.

  7. Overview of the Monitor Framework capabilities

    master

    The monitor framework provides a structured way to manage the lifecycle of monitoring data through three core capabilities:

    1. Data Flow Management: Implements a complete pipeline of Collection -> Storage -> Reporting. Currently, an in-memory queue is used as the storage mechanism. The frequency of queue storage and reporting can be adjusted via configuration.
    2. Extensibility: All monitoring data is abstracted using the Content interface. While the framework includes a built-in Alarm struct for internal alerting, users can implement the Content interface to support third-party monitoring requirements.
    3. Plugin Architecture: Monitoring components are plugin-based. The framework supports different plugins to determine how data is processed and reported. Currently, supported plugins include blueking and noop (the default, which performs no operations).
  8. Understand the Filter Module Overview

    master

    The pkg/filter module is a backend component designed to parse universal query parameters from frontends or APIs into MongoDB filter conditions.

    Key features include:

    • Type Safety: Only allows querying fields supported by the specific data type. It enforces matching between the field type and the query value (e.g., querying a string field with a string value) to prevent silent failures or incorrect results.
    • Supported Types: Supports basic types (numeric, boolean, string, time) and complex structures (arrays and objects).
    • Logical Composition: Supports combining multiple field queries using AND and OR logic, as well as nested structure queries.
    • Backward Compatibility: Compatible with previous versions of querybuilder parameters to facilitate migration.
  9. Define database table business indexes

    master

    The src/common/index package is used to define business indexes required for database tables. It provides index definitions and helper functions for comparison and lookup.

    Index Definition Structure

    Indexes are defined as a slice of types.Index: Index definition = []types.Index{}

    Index Types

    There are two main categories of index definitions used for synchronization with the database:

    1. comm prefix indexes: These are normalized indexes. The index name must start with either CCLogicUniqueIdxNamePrefix or common.CCLogicIndexNamePrefix.
    2. deprecated prefix indexes: These are unnormalized (legacy) indexes.

    Registering Indexes

    Indexes are registered in the package's init() function using registerIndexes:

    func init() {
    	// Register unnormalized indexes first. If conflicts occur, unnormalized indexes are deleted.
    	registerIndexes("database_table_name", indexDefinition)
    }