- Product deployment architecture
Introduce the roles, features, and components of product nodes.
| Module/Container | Node Type | Component Introduction |
|---|---|---|
| tcloud-barad-update2 | Container | It contains Stargate servers and alarm loading services. 1. The Stargate server provides services for the Stargate agent (ps aux | grep sgagent) on the CVM, mainly used to record and update CVM status information as well as distribute BARAD agents. 1. The alarm loading service is a unified query service designed to reduce database queries of the storm supervisor. It caches a copy of the alarm configuration data in the database to the /data/www/alarmdb.barad.yun.com/alarm_file directory in the container, and exposes an HTTP service through Nginx for the storm supervisor to pull. |
| tcloud-barad-event | Container | Contains event center CGI and handler services. 1. Event center CGI provides HTTP services for other vertical products to report events. After simple verification of the reported events, it writes them to TDMQ for Kafka. The topic configuration is cm_event. 1. The handler service consumes data from TDMQ for Kafka and converges repeatedly reported events (the basis for judgment of repeated reports is: whether the alarm object is the same, determined by the StormCloudConf.cEventProductConfig.astrictDimension field; the convergence duration, determined by the StormCloudConf.cEventProductConfig.astricPeriod), performs verification, detects whether an alarm policy is configured, and stores the data in ES. If an alarm policy is configured, it sends an HTTP request to ams to trigger an alarm. 1. For multi-region deployment, the tcloud-barad-event image should be deployed in each region. |
| tcloud-barad-isd | Container | Contains multiple backend management services and scripts, the service for timeout detection of Overlay instance agent reporting (to be removed soon), and the service for pulling configurations from the Cloud Monitor configuration center. Generally, multiple instances are not required. Other containers generally have the ConfClient component to cache configurations in the Cloud Monitor configuration center. |
| tcloud-barad-dispatch-tsm | Container | Contains only one service that imports the data of some Cloud Monitor namespace into Argus. |
| tcloud-barad-script | Container | Contains 5 bypass services. 1. barad_sync_server automatically synchronizes CVM information from CCDB to the translation table for NWS to perform dimension translation. 1. cm_php_script is used to synchronize alarm policy information of the primary database to the regional database. 1. dict_access, a server for reporting dimension translation information for other products, caches data into TDMQ for Kafka. The Topic list is the table of tDictionary_* in the StormDictionary library. It is recommended to create only two partitions for each topic. Otherwise, the container will continuously restart because of too many processes. 1. dict_sync consumes dimension translation information from TDMQ for Kafka, and then stores it in the database (to form a complete service together with dict_access). 1. The role of getAppTraffic is to obtain traffic data of the view under qce/lb in each region, aggregate and calculate the total inbound/outbound traffic of each tenant to qce/lb_total, and display it in the traffic monitoring column on the tenant side. |
| tcloud-barad-dataapi | Container | Contains two services: dataapi and newdataapi. Both are old APIs. They may be removed later because there are few callers. |
| tcloud-barad-nws | Container | Contains three services. The NWS service is used to receive FT report data, perform legality judgments on the data, perform dimension translation, and then store it in TDMQ for Kafka. The feature of NWS to perform dimension translation is guaranteed by dict_loader. This component caches the dimension translation information from the DB to the /data/storm/local_dict/ directory in the container (the information in the DB is written by dict_access and dict_sync of tcloud-barad-script). The container also has a special CGI. The custom alarm receiving feature is provided by customAlarmNws. Users can customize alarms through cagent_tools on the CVM. Since the feature involves complex components, details will not be given here. |
| tcloud-barad-alarm | Container | Contains only the service cloud_alarm and mainly provides two external services. One service receives storms and reverses and transmits the alarm status (normal > abnormal > alarm > normal). The other receives platform events. |
| tcloud-barad-api | Container | Contains customapi, baradapi, ams, customAlarm, and policyapi. customapi integrates with Cloud API Management and provides a frontend API and some open APIs. Cloud Monitor API encapsulates the logic for calling ES, equivalent to an ES client exclusive to Cloud Monitor. ams, located downstream of tcloud-barad-alarm, is used to record alarm information, connect to the message center, and send alarms. customAlarm, a custom alarm related to tcloud-barad-nws, is used to update clientkey into CKV. New policyapi 342 derives from customapi. |
| tcloud-barad-skywalker | Container | Contains Flink stream computation logic components and their management scripts. |
| product-barad-deploy | Container | As a production component used for deployment, it needs to be further improved. Some practical tools, such as the tool fix_es_table_err under TCE/tools/fix that fixes the timestamp type of ES tables to mills, and the tool fix_ft_host that fixes the hard-coded domain name in the ft callback API of the database can be deployed without this component. |
| product-barad-sgagent | As a standardized component of Stargate agent, it executes deploy to directly standardize Stargate agent and transmit it to HDFS for download and installation when the host creates CVM instances. | |
| yunapi-barad | Cloud API Management configuration of BARAD | |
| tcloud-barad-api-go | Cloud Monitor API V3, which is derived mostly by modifying the policy API. The policy API is a V2 API, which should be upgraded to V3 in private cloud environments. Therefore, a proxy is implemented for tcloud-barad-api-go to convert parameters of gateway requests via V3 APIs. The parameters are converted into those for V2 APIs to call the policy API. |
- Restarting the pod in general
In general, directly restart the pod where the component is located, and Kubernetes will automatically perform load traffic transfer. After deletion, it will automatically start and switch back to the cluster.- Obtain the Cloud Monitor Pod list: kubectlget pod --all-namespaces -o wide |grep barad
- Delete a Pod: kubectl delete pod -n tce ${pod}
- Wait until the start status is:
- Restarting by component
- Obtain the Cloud Monitor Pod list: kubectl get pod --all-namespaces-o wide |grep barad-nws
- Enter pod: kubectl exec -it -n tce ${pod}bash.
- The directory where the component is located in general: /usr/local/services/.
- sh/usr/local/services/barad_nws-1.0/admin/restart.sh all
Normal:
