Skip to content

Tenant Configuration

Tenant Level Settings

Each tenant is associated with a configuration file where per tenant properties are set. As of today each tenant is provided with a single propertyto define the zookeeper cluster in charge of providing the configuration and runtime database to be used.

1
2
3
4
5
{
    // the value defined here MUST correspond to a zookeeper cluster
    // defined in the punchplatform.properties.
    "admin_zk_cluster" : "common"
}

Tenant Indices

The punch relies on elasticsearch not only to store the user business data, but also to centralize metrics and inner logs so as to provide operators with a simple and efficient mean to understand the platform and their application behavior.

As a concrete example we will assume you have a platform with two tenants:

  • mytenant : the user applicative tenant. This is where users will setup business or administrative channels. Note that administrative channels refer here to channels in charge of dealing with user data and resources associated to that tenant only.
  • platform : on production platforms, a tenant called platform is defined to deal with platform level monitoring data. Servers cpu, network usage or any other platform level resource is monitored, and in turn have a natural platform level scope.

Tip

Daily weekly or monthly indices are very common. These are depicted hereafter using a mytenant-events-* notation. Using daily indices you will have one index per day mytenant-events-2019.05.09, mytenant-events-2019.05.10 etc..

Index Description
mytenant-events-* user data are stored in indices prefixed with the tenant's name. The 'events' part here is only illustrative.
mytenant-metrics-* Punch applicative components publish their metrics to daily per tenant indices.
platform-metricbeat-* The punch monitoring service periodically publishes a consolidated platform status document. It is in turn exposed using through the elasticsearch REST api to external supervisors. It provides a complete view of the health status of all platform components (Storm, Spark, Shiva, Elasticsearch, Zookeeper, etc).
platform-monitoring-current The punch monitoring service also publish data to this index to keep track of the latest individual component status.
platform-monitoring-* In this last daily index the (once again) mpunch monitoring service keeps track of the complete monitoring history.
platform-logs-* This index contains the platform administrative logs. It contsins the start and stop actions performed by users (punchctl), as well as all Shiva related actions. This index allows a fine grain monitoring of all platform and shiva scheduled jobs. It also provide an history of all operator commands.
platform-plan-cursor-* Provides the ability for a plan to checkpoint the last succesfull execution. Hence, enabling resilient plans executions. Jobs that are executed are based on an advancing timestamp watermark...

Important

The precise naming depends on your final configuration, in particular daily monthly or time independant indices are setup in channel configurations. What is however enforced is the tenant prefixe usage, and the platform level indices naming scheme. Overall these naming strategi is also required for enforcing security.