Chat now with support
Chat with Support

Welcome, Quadrotech customers to Quest Support Portal click here for for frequently asked questions regarding servicing your supported assets.

Foglight 5.9.5 - Data Model Guide

The Foglight data model Data modeling tutorials Appendix: Groovy scripts Appendix: Internal database schema
acl_class Table acl_entry Table acl_object_identity Table acl_sid Table agent_client_defaults Table agent_config_binder Table agent_dc_manager_schedule_ids Table agent_dc_manager_state Table agent_manager_state Table alarm_alarm Table alarm_annotations Table alarm_loc_msg Table auditing_log Table baseline_config Table baseline_config_properties Table baseline_engine_profile Table baseline_observation_profile Table cartridge_cartridge_relation Table cartridge_components Table cartridge_installed_cartridges Table cartridge_items Table credential_data Table credential_lockbox Table credential_mapping Table credential_mapping_entry Table credential_order Table credential_policy Table current_version Table database_instance_id Table database_version Table derivation_calculation Table derivation_complex_definition Table derivation_definition Table fgl4_migration_agent Table fgl4_migration_data_span Table fgl4_migration_dcm Table fgl4_migration_host Table fgl4_migration_host_mapping Table fgl4_migration_log Table fgl4_migration_server Table incident_affected_objects Table incident_incident Table incident_linked_alarms Table incident_problem_ticket Table incident_problem_tickets Table licensing_licenses Table mgmt_object_size Table mgmt_observation_size Table mgmt_timeslice Table mgmt_timeslice_data_avail Table model_association Table model_property_formula Table model_query_criteria Table obs_binary_* Tables obs_metric_aggregate_* Tables obs_metric_scalar_* Tables obs_string_* Tables pcm_encoded_data Table persistable_config_model Table persistable_script Table persistence_column_mapping Table persistence_db_column Table persistence_db_schema Table persistence_db_table Table persistence_grouping_policy Table persistence_lifecycle Table persistence_lifecycle_period Table persistence_obs_key_purge_age Table persistence_obs_purge Table persistence_obs_purge_age Table persistence_observation_index Table persistence_operation Table persistence_retention_policy Table persistence_rollup_progress Table persistence_rollup_retry Table persistence_storage_config_xml Table persistence_storage_manager Table persistence_timeslice_table Table persistence_topobj_purge_age Table persistence_type_hierarchy Table registry_performance_calendar Table registry_registry_value Table registry_registry_variable Table report_output Table report_schedule Table rule_action_handler Table rule_action_message Table rule_action_registry_reference Table rule_action_variable_reference Table rule_blackout_schedules Table rule_effective_schedules Table rule_expression Table rule_firing_strategy Table rule_messages Table rule_rule Table rule_sev_to_clear_actn_hndlr Table rule_sev_to_fire_actn_hndlr Table rule_severity Table rule_severity_expression Table rule_severity_messages Table schedule_named_schedule Table script_annt Table script_annt_attr Table script_argument Table script_argument_annt Table script_argument_annt_attr Table script_example Table script_return_annt Table script_return_annt_attr Table sec_group Table sec_group_nesting Table sec_group_role_match Table sec_grouprole Table sec_jaas_source Table sec_object Table sec_object_mask Table sec_object_permission Table sec_object_type Table sec_permission Table sec_permission_def Table sec_policy Table sec_resource Table sec_role Table sec_user_alias Table sec_user_obj_permission Table sec_user_res_permission Table sec_usergroup Table sec_userrole Table sec_x_attribute Table sec_x_attribute_value Table tagging_service_mapping Table threshold_bound Table threshold_config Table topology_activity_calendar Table topology_activity_upgrade Table topology_object Table topology_object_history Table topology_property Table topology_property_annotation Table topology_property_history Table topology_property_name Table topology_property_value Table topology_service_state Table topology_type Table topology_type_annotation Table topology_type_history Table upgrade_pending_operations Table wcf_groups_by_cartridges Table wcf_resources Table

How are models organized?

In the Data dashboard, the top-level nodes are based on root queries. The entries that appear in the Data tree are instances of the types defined in the data model. Thus, not all defined types appear, but only those types for which Agents have created at least one instance.

These queries are defined in modules and they use the module name as the node name. There are several nodes that are always present because they are root queries defined in the Management Server. Other nodes may be present. They originate from root queries defined in cartridges that have been installed on the Management Server.

Some examples are:

Alarms — Current Alarms and Outstanding Alarms
Hosts — All Hosts
Management Server — All Agents, All Data, Schema, and Servers
Services — All Model Roots, All Object Groups, All Service Categories, All Services, and All System Services

For example, the common Host model is a topology model defined in the Management Server to describe the host objects being monitored. The use of a common model allows the Management Server to provide out-of-the-box configuration for visualizing hosts that could be monitored by any type of agent.

For more information, see:

Where can I see the data model hierarchy?

All data models have a root. In the Management Server’s user interface, Dashboards > Configuration > Data > Management Server > All Data is considered the root (“/”) in the dashboard framework. The All Data node contains references to the ModelRoot topology instances. A data object shows up under Management Server > All Data if it is defined in topology-types.xml file.

While it is possible for a cartridge to add a root property by explicitly defining the property in the cartridge’s topology-types.xml file, changing types in this way is not encouraged. It is better for the cartridge to provide a new model root, so that a property is added automatically.

The cartridge can do this by defining a topology type in its schema that extends the core "ModelRoot" type. For example:

When the new root type is created, the server automatically adds a corresponding property to the Root type that returns instances of that model root. The cartridge then needs to create a single instance of that type and reference the top-level domain objects. The topology types used for top-level domain objects should be annotated with the core "DomainRoot" annotation, so that they can be configured with the admin grouping functionality. For more information about domains, see the What are domains? topic.

For example:

What internal models are created?

The Management Server builds internal models for its own activities.

What other models are created?


Related Documents