application.yml shows the service's entire runtime config (Kafka bootstrap servers, thread-pool sizing, HTTP client-pool tuning, etc.) is pulled live from a shared internal Nacos config server, filed under Nacos config group "Galaxy" with data-id "p19-file-sync-service" -- direct confirmation that Nacos organizes Galaxy's constituent microservices (including this Pakistan-site one) under a single logical group, consistent with the taxonomy's 40+-repo galaxy-data-platform description. Separately, KafkaConsumer.java shows the underlying Kafka bus enables SASL_PLAINTEXT authentication (PLAIN mechanism, username/password sourced from the same Nacos config) specifically when the configured broker address contains port 9094, implying at least two logically distinct Kafka listener classes (authenticated on 9094 vs. unauthenticated elsewhere) on the shared bus this file-sync pipeline consumes from.

This P19 (Pakistan) service is a pure Kafka-triggered file relay: for each Kafka record it deserializes a SysFileSync payload carrying a list of {source_oss_path, destination_oss_path} pairs alongside common_log_id, common_recv_time, common_schema_type, and processing_time -- fields matching the shared session/event-log schema used elsewhere in the MESA platform -- then HTTP-GETs each file from its source path and HTTP-POSTs it to its destination path. Distinct hosError/ossError/fileSyncError counters for the two legs (source read vs. destination write) show the two endpoints are operated as separate storage systems, one referred to in logs as "Hos" and the other as "Oss". Net effect: file objects tied to individually logged monitored sessions at the Pakistan site are relayed between storage tiers as a matter of routine pipeline operation, not just session metadata.

The repo galaxy/tsg_olap/p19-file-sync-service.bundle is a dedicated, site-scoped microservice explicitly namespaced for P19 -- this corpus's Pakistan deployment codename (site_codenames: "WMS-UTR / P19: Pakistan"). Its Docker image is built under the tsg/galaxy Harbor namespace (192.168.40.153:9080/tsg/galaxy/p19-file-sync-service), and its container WORKDIR/MAINTAINER are both "galaxy", directly confirming that Galaxy (the OLAP/big-data layer documented elsewhere in this taxonomy) ships individually-built, per-customer-site production services out of its tsg_olap subtree rather than only shared library code. The pom.xml calendar version (23.09.26) pins this specific build to Sept 26, 2023.

CyberNarrator's flink-stream-schedule-platform runs its own volumetric-DDoS "sketch" detection consumer (DosSketchEtl, wired in via business.properties' dos.sketch.etl.class) that is architecturally separate from Galaxy's own storm-based DoS pipeline. Each Kafka message is a batched detection window (sketch_start_time, sketch_duration, attack_type) carrying a nested report_ip_list that the ETL explodes into one record per flagged source/destination IP pair with session, packet, and byte counters, each tagged with the originating "sled" appliance IP and data center — i.e. detection happens upstream on distributed sensor appliances that emit periodic aggregate sketches rather than raw flow records, and this stream-schedule platform is a generic reflection-based Flink job runner (one Schedule implementation class instantiated per business.properties entry) reused across CyberNarrator's ETL jobs.

The DOS-SKETCH-RECORD Kafka input topic CyberNarrator's flink-stream-schedule-platform consumes from is SASL-authenticated with a hardcoded, product-branded credential (redacted here — see evidence_quote note) against internal brokers on port 9094 — the password itself embeds the Galaxy product name and an apparent 2019 provisioning year — which, together with cn-web/cn-admin's dedicated (if still-unimplemented) net.geedge.modules.galaxy.controller.GalaxyController class already seen alongside GalaxyProxyController/GalaxyResolveController, corroborates that CyberNarrator's backend infrastructure was bootstrapped under and remains operationally tied to the Galaxy platform rather than being a fully independent product line.

Release 24.04 (28 APR 2024) adds province/city-granularity ("administrative area") geo-tagging to every session and security-event log for both client and server -- client_country/client_super_administrative_area/ client_administrative_area/client_sub_administrative_area and the server-side equivalents -- plus Client ASN/Server ASN as dedicated Statistics Rule Metric datasets, confirming sub-national geolocation is a standard enrichment field across TSG's logging pipeline, not a specialized lookup.

The app_recommend Flink job (Recommendation.java, job name "RECOMMENDATION-APP-CIP") keys incoming traffic by (app_label, client_ip), computes a sliding-window top-N of active client IPs per identified application via TopnHotItem's priority queue, and HbaseSink persists the result as an app-to-client-IP-list association -- row key MD5(app_label), columns app_label/client_ip_list/last_update_time -- in HBase. This is the source of the "Recommend App Active Client IP" troubleshooting lookup referenced in galaxy-troubleshooting-api's Release 21.12 changelog.