7.2 Demonstrating monitoring and analysis capabilities
7.2.2 Cloud Application Platform consumer’s perspective
The second part of the case study is intended to demonstrate the consumer’s perspective on the monitoring process and how CAP users can benefit from using the EXCLAIM framework.
With several samples, we will illustrate how the framework is able to detect an excessive number of client connections to Heroku’s PostgreSQL database service.
Heroku’s pricing model offers customers a range of subscription plans, each associated with certain service levels – i.e., amount of metered and billed resources available to the user. In particular, a typical metric relating to data storage services is the number of simultaneous client connections. However, customers are not currently notified in advance when the number of active connections is reaching ‘danger levels’, and this can result in further connection requests being unexpect- edly rejected. Accordingly, our goal in this case study was to equip data storage services with sensing capabilities, so that application providers can be notified in advance whenever a threshold is approaching, allowing them to take appropriate pre-emptive actions – for example, by closing down low-priority connections or by automatically upgrading their subscription plan.
Using our framework, we manually annotated sensory data (in this case, the current pool of client connections and the current state of the database backup process) with semantic descriptions defined in the CSO to generate a homoge- neous data representation, and then streamed these RDF values to the C-SPARQL querying engine.1 The maximum number of client connections for the initial sub- scription plan is limited to 20, and our goal was to detect situations when this number increases and approaches the danger level.
1To extract these metrics from the PostgreSQL service we relied on standard mechanisms offered by this database. See Table 7.1 for details of how this can be done.
Services and SBAs can be classified with respect to their criticality level (i.e., minor, moderate, and critical). Destinator, being a data-intensive application heav- ily depending on the underlying data storage service PostgreSQL, is therefore can be classified as critical in terms of its data storage service, and corresponding di- agnosis policies have to be applied in this respect. Accordingly, as the critical level threshold we defined the value of database client connections to be 15 – it means that the EXCLAIM framework has to be particularly sensitive to Destinator, and detect potential critical situations well before the number of connections reaches 20 so as to notify the customer in advance and ensure application stability.
The following RDF stream in Listing 7.5 represents a situation when the num- ber of client connections increased from 12 to 15, and no backup process is running – this is important because the backup process establishes two client connections to the database, but typically lasts for less than a minute, and therefore should not be considered as a threat.
Listing 7.5: RDF triples on the stream indicate an increase in the number of client connections to the PostgreSQL service from 12 to 15 connections with no backup process running.
cso:postgres-service-10 rdf:type cso: HerokuPostgresService cso:postgres-service-10 cso:hasNumberOfConnections cso:number-of-
connections-122
cso:number-of-connections-122 rdf:type cso:NumberOfConnections cso:number-of-connections-122 cso:hasValue "12"^xsd:int
cso:postgres-service-10 rdf:type cso: HerokuPostgresService cso:postgres-service-10 cso:hasNumberOfConnections cso:number-of-
connections-122
cso:number-of-connections-122 rdf:type cso:NumberOfConnections cso:number-of-connections-122 cso:hasValue "13"^^xsd:int
cso:postgres-service-10 rdf:type cso: HerokuPostgresService cso:postgres-service-10 cso:hasNumberOfConnections cso:number-of-
connections-122
cso:number-of-connections-122 rdf:type cso:NumberOfConnections cso:number-of-connections-122 cso:hasValue "14"^^xsd:int
cso:backup-service-8 rdf:type cso:BackupService
cso:backup-service-8 cso:accesses cso:postgres-service-10 cso:backup-service-8 cso:isActive "false"^^xsd:boolean
cso:postgres-service-10 rdf:type cso: HerokuPostgresService cso:postgres-service-10 cso:hasNumberOfConnections cso:number-of-
connections-122
cso:number-of-connections-122 cso:hasValue "15"^^xsd:int
In order to assess the current situation and detect violations we registered a set of standing C-SPARQL queries, which are evaluated 10 times per second (i.e., queries are evaluated every 100 ms). Listings 7.6, 7.7, and 7.8 represent the critical- level, moderate-level and minor-level criticality queries respectively. It needs to be noted that these three queries represent the previously-explained concept of application profiling (see Section 5.3) – that is, when users deploy their software, they can specify how sensitive they are in terms of particular add-on services. Such an application profile allows the framework to apply a differentiated approach to problem detection – i.e., in some circumstances a potentially critical situation can be tolerated, whereas in some others (more sensitive) occasions it has to be treated carefully.
As it is seen from the listings, the conditions specified in the WHERE clauses are mutually exclusive, which means that only one query will trigger at a time. The WHERE clause specifies the actual danger threshold for the PostgreSQL service’s client connections, and in the considered scenario it will trigger whenever the number of client connections during the previous minute reaches the threshold of 15 at least once, provided there is no backup process running – that is, there are indeed 15 connected clients, and there is a potential threat to the application stability.
Listing 7.6: Detecting number of client connections at the critical level.
REGISTER STREAM CriticalStream
AS PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX cso: <http://seerc.org/ontology.owl#>
CONSTRUCT { ?service rdf:type cso:HerokuPostgresService . ?service cso:hasNumberOfConnectionsCritical
"true^^http://www.w3.org/2001/XMLSchema#boolean" } FROM STREAM <http://seerc.org/rdf/stream/> [RANGE 1m STEP 100ms] WHERE { ?service rdf:type cso:HerokuPostgresService .
?service cso:hasNumberOfConnections ?numConn . ?numConn rdf:type cso:NumberOfConnections . ?numConn cso:hasValue ?v .
?bservice rdf:type cso:BackupService . ?bservice cso:accesses ?service .
?bservice cso:isActive "false^^http://www.w3.org/2001/XMLSchema# boolean"
FILTER ( ?v >= 15 && ?v < 17) }
Listing 7.7: Detecting number of client connections at the moderate level.
AS PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX cso: <http://seerc.org/ontology.owl#>
CONSTRUCT { ?service rdf:type cso:HerokuPostgresService . ?service cso:hasNumberOfConnectionsModerate
"true^^http://www.w3.org/2001/XMLSchema#boolean" } FROM STREAM <http://seerc.org/rdf/stream/> [RANGE 1m STEP 100ms] WHERE { ?service rdf:type cso:HerokuPostgresService .
?service cso:hasNumberOfConnections ?numConn . ?numConn rdf:type cso:NumberOfConnections .
?numConn cso:hasValue ?v .?bservice rdf:type cso:BackupService . ?bservice cso:accesses ?service .
?bservice cso:isActive "false^^http://www.w3.org/2001/XMLSchema# boolean"
FILTER ( ?v >= 17 && ?v < 19) }
Listing 7.8: Detecting number of client connections at the minor level.
REGISTER STREAM CriticalStream
AS PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> PREFIX cso: <http://seerc.org/ontology.owl#>
CONSTRUCT { ?service rdf:type cso:HerokuPostgresService . ?service cso:hasNumberOfConnectionsMinor
"true^^http://www.w3.org/2001/XMLSchema#boolean" } FROM STREAM <http://seerc.org/rdf/stream/> [RANGE 1m STEP 100ms] WHERE { ?service rdf:type cso:HerokuPostgresService .
?service cso:hasNumberOfConnections ?numConn . ?numConn rdf:type cso:NumberOfConnections . ?numConn cso:hasValue ?v .
?bservice rdf:type cso:BackupService . ?bservice cso:accesses ?service .
?bservice cso:isActive "false^^http://www.w3.org/2001/XMLSchema# boolean"
FILTER ( ?v >= 19) }
The REGISTER and CONSTRUCT clauses of the presented C-SPARQL queries serve to define a new RDF stream called CriticalStream, which only contains critical observations. Once any new triples appear on the stream, they are imme- diately added to the ABox of the CSO – that is, the ontology is populated with respective RDF triples. In our scenario, the CSO is populated with the following two triples defined in Listing 7.9:
Listing 7.9: The CSO is populated with RDF triples representing a critical situation.
cso:postgres-service-10 rdf:type cso: HerokuPostgresService
cso:postgres-service-10 cso:hasNumberOfConnectionsCritical "true"^^http: //www.w3.org/2001/XMLSchema#boolean
After they have been added to the ontology, the reasoning process is initiated. It is the most computationally-intensive part of the monitoring and analysis pro- cedure, and we support this process by minimising the TBox of the CSO, and thus minimising the number of logical axioms with respect to which the reasoner eval- uates the newly-added triples. Listing 7.10 contains SWRL rules, which can be potentially applied in this respect so as to classify the observed situation as critical or not.
Listing 7.10: Only one of the three SWRL rules, determining whether an observed situation is indeed critical or not, is added to the TBox of the knowledge base.
HerokuPostgresService(?s), hasNumberOfConnectionsMinor(?s, true) -> CriticalNumberOfConnections(?s)
HerokuPostgresService(?s), hasNumberOfConnectionsModerate(?s, true) -> CriticalNumberOfConnections(?s)
HerokuPostgresService(?s), hasNumberOfConnectionsCritical(?s, true) -> CriticalNumberOfConnections(?s)
This is where the two framework enhancements, described in Sections 5.3.1 and 5.3.2, again come into play. Since we classified Destinator as a data-intensive application demanding for critical-level policies to be applied, the knowledge base (i.e., the TBox) only includes the third SWRL rule from Listing 7.10. This rule is uploaded dynamically at run-time from a remote location (where it is maintained by the respective service provider) by following its URI and importing the fetched document into memory of the reasoning engine, as prescibed by the Linked Data principles. As a result, the monitored HerokuPostgresService instance is eval- uated against a limited, yet targeted policies, and classified as belonging to the CriticalNumberOfClientConnectionsclass.
The last step in this analysis process is to see if there are any instances of the class CriticalSituation. As it is illustrated in Figure 6.5, the class Critical- NumberOfClientConnectionsis a subclass of the class CriticalSituation, and the reasoner, resolving this subclass dependency, marks HerokuPostgres- Serviceas a critical situation. As a result, the EXCLAIM framework notifies the user of a detected critical situation.
It is worth noting that application profiling and enforcing of different-level policies only takes place at the very last step of OWL/SWRL reasoning. The C- SPARQL queries might have detected all three cases, when the number of client connections is gradually increasing from minor to moderate, and, eventually, to critical level (i.e., from 12 to 19, thus satisfying the WHERE conditions of all three queries in Listings 7.6, 7.7, and 7.8), and corresponding RDF triples are sent to the critical stream. However, as long as there are no SWRL rules added to the know-
ledge base, these values will not be marked as critical situations by the reasoner, which will only rely on the default, core ontology when resolving dependencies.
To justify the use of SWRL as a language for defining policies, we now demon- strate how its reasoning support can benefit the detection process. Listing 7.10 contains rules, which can only apply to a single database service available through Heroku marketplace – that is, HerokuPostgres. As indicated by Figure 8.8, it is a child of a higher-level class DatabaseService together with several other ser- vices. Accordingly, it is possible to rewrite the policies to make them more generic and applicable across all database services. By doing so, we benefit from SWRL’s capabilities to resolve sub-class relationships, and minimise the amount of redun- dant policies. Listing 7.11 contains these generic rules:
Listing 7.11: Generic rules apply to all sub-classes of the class DatabaseService.
DatabaseService(?s), hasNumberOfConnectionsMinor(?s, true) -> CriticalNumberOfConnections(?s)
DatabaseService(?s), hasNumberOfConnectionsModerate(?s, true) -> CriticalNumberOfConnections(?s)
DatabaseService(?s), hasNumberOfConnectionsCritical(?s, true) -> CriticalNumberOfConnections(?s)