- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi All,
i trust this email finds you well.
1) i have a request to track ports used by the db instance (sql, mysql, mongodb, etc). I noticed there is a field called "TCP ports" which is a string field and can store multiple port numbers separated by a symbol of my choice. i wonder if there is another table for ports, so i can create a relationship between the db instance and ports used. i am not sure using the OOB port field is efficient.
2) is there a class for AWS EC2 servers?
3) is there a class for AWS EKS?
regards.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Regarding port tracking, ServiceNow does not provide an out-of-the-box Port CI table that supports normalized relationships to database instances that I know of; the OOB TCP Ports stringg field is the standard approach, with port usage primarily inferred through Discovery and Service Mapping via process, listener, and endpoint relationships rather than a standalone Port CI, and creating a custom Port table would require non-OOB customization and ongoing maintenance. For AWS, ServiceNow does provide native CMDB classes: EC2 instances are represented by cmdb_ci_ec2_instance ( extending cmdb_ci_vm_instance / cmdb_ci_compute), and AWS EKS is supported through Kubernetes classes such as cmdb_ci_k8s_cluster, cmdb_ci_k8s_node, cmdb_ci_k8s_namespace, and cmdb_ci_k8s_pod, typically populated via Service Graph Connector for AWS or Kubernetes integrations. Let me know if this helps
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Regarding port tracking, ServiceNow does not provide an out-of-the-box Port CI table that supports normalized relationships to database instances that I know of; the OOB TCP Ports stringg field is the standard approach, with port usage primarily inferred through Discovery and Service Mapping via process, listener, and endpoint relationships rather than a standalone Port CI, and creating a custom Port table would require non-OOB customization and ongoing maintenance. For AWS, ServiceNow does provide native CMDB classes: EC2 instances are represented by cmdb_ci_ec2_instance ( extending cmdb_ci_vm_instance / cmdb_ci_compute), and AWS EKS is supported through Kubernetes classes such as cmdb_ci_k8s_cluster, cmdb_ci_k8s_node, cmdb_ci_k8s_namespace, and cmdb_ci_k8s_pod, typically populated via Service Graph Connector for AWS or Kubernetes integrations. Let me know if this helps
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Hi Matt,
thanks for taking the time to answer my questions.
2 and 3 are ok.
in terms of Q1: i decided to use cmdb_ci_port table and created a relationship to cmdb_ci. Also added following fields :
port number
primary port
protocol
do u think it is a bad idea or should be ok?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
It’s not inherently a bad idea. Using cmdb_ci_port can work if you need a normalized way to represent DB listener ports and you have clear ownership and a reliable way to keep the data current. The main risks are semantic confusion (network ports vs. application listener ports) and data staleness if updates are manual. To reduce risk, keep customization light, use a clear relationship type (e.g., “Listens on”), and consider a custom extension or naming convention to distinguish DB ports.