Create server classes

A server class maps a group of deployment clients to one or more deployment apps. By creating a server class, you are telling the deployment server that a set of clients should receive updates in the form of a set of apps.

Ways to group clients

A client grouping can be based on a variety of criteria, such as machine type, OS, geographical area, or application type.

A client can belong to multiple server classes. For example, a Windows forwarder located in Kelowna and providing information to the Web hosting team might belong to three server classes: "canada", "windows", and "web_host". This diagram shows how clients can span multiple server classes:

In this example, each deployment client is a Splunk Enterprise forwarder that belongs to two server classes, one for its OS and the other for its geographical location. The deployment server maintains the list of server classes and uses those server classes to determine what content to distribute to each client. For an example of how to implement this type of arrangement to govern the flow of content to clients, see "Deploy configurations to several forwarders".

Another common way to group clients is to define one server class that applies to all deployment clients by default. You can then override various aspects of it as needed by defining more specific server classes for subgroups of clients. For example, if you have a mix of Windows and Linux universal forwarders sending data to the same indexer, you can specify that all forwarders get a common outputs.conf file, but that Windows forwarders get one inputs.conf file while Linux forwarders get a different one. To implement this, you can define an "all forwarder" server class that distributes a deployment app containing a common outputs.conf file to all forwarders, while also defining Windows and Linux server classes that distribute separate apps containing different inputs.conf files to the appropriate subsets of forwarders.

Overview of server class configuration

A server class is a mapping between deployment clients and apps. It tells the deployment server which apps to send to which clients. Therefore, when you define a server class, you associate one or more apps with a group of deployment clients.

You define server classes on the deployment server with these steps:

1. Create the server class.

2. Specify one or more deployment apps for the server class.

3. Specify the clients that belong to the server class.

This section provides an overview of these steps. The specifics of the configuration process depend on the method you use to create the server class: the forwarder management interface or direct editing of serverclass.conf. See "Ways to define server classes".

1. Create the server class

Create and name the server class through the forwarder management interface or directly in serverclass.conf.

Important: Server class names must be unique.

2. Specify apps for the server class

Once you've created the server class, you need to associate deployment apps with it. These are the apps that you earlier created on the deployment server's file system, as described in "Create deployment apps". There is not necessarily a one-to-one correspondence between server classes and apps. Rather, a single server class can include several apps. Similarly, one app can belong to multiple server classes.

3. Specify clients for the server class

Next, you need to associate clients with the server class. You do not ordinarily specify clients individually. Instead, you set up filters that dynamically determine which clients belong to the server class, based on common identifiable characteristics.

Ways to define server classes

You define server classes on the deployment server. Server class definitions are saved in the deployment server's serverclass.conf file. There are two ways to define server classes:

• By using the forwarder management interface. See "Use forwarder management to define server classes" for details. This is the easy way to define server classes. It offers a quick, interactive approach to filtering clients and mapping them to apps.

• By directly editing the deployment server's serverclass.conf file. See "Use serverclass.conf to define server classes" for details. Some advanced configurations require that you directly edit serverclass.conf.

Important: Once you edit serverclass.conf directly, you will probably not be able to use the forwarder management interface for subsequent configuration. This is because forwarder management can handle only a subset of possible configurations. For details on what serverclass.conf changes are compatible with forwarder management, see the topic "Compatibility and forwarder management".

The serverclass.conf file

The serverclass.conf file is the key deployment server configuration file. All server class definitions get written to that file. In addition, it holds a number of other settings related to the functioning of the deployment server. For a detailed description of that file, including a list of all configuration attributes, read the serverclass.conf specification file.

For background information on Splunk Enterprise configuration files, read "About configuration files" in the Admin Manual.

When the forwarder management interface configures server classes, it writes the definitions to a copy of serverclass.conf. You can also edit serverclass.conf directly, and you might need to do so for some complex configurations.

The deployment server can have multiple versions of serverclass.conf. When there are multiple versions of a configuration file, Splunk Enterprise follows a defined process for merging the attributes from all the versions. For details on the order of precedence that Splunk Enterprise uses, read "Configuration file precedence" in the Admin Manual.

When you use forwarder management to create a new server class, it saves the server class definition in a copy of serverclass.conf under $SPLUNK_HOME/etc/system/local. If, instead of using forwarder management, you decide to directly edit serverclass.conf, it is recommended that you create the serverclass.conf file in that same directory, $SPLUNK_HOME/etc/system/local.

If a server class definition exists in a serverclass.conf file under some other directory (most typically an app directory located at $SPLUNK_HOME/etc/apps/<app_name>/local), the forwarder management interface will still display that server class, along with any other server class definitions located in files elsewhere on the system. If you use forwarder management to edit an existing server class, the interface will save the edits to the same version of serverclass.conf. That is, if you edit a server class that's defined in $SPLUNK_HOME/etc/apps/SomeApp/local/serverclass.conf, forwarder management saves the updated definition back to that same directory. However, if you then use forwarder management to create a new server class, it saves the new server class to $SPLUNK_HOME/etc/system/local/serverclass.conf.

Important: Server class names must be unique across all serverclass.conf files.