Data Collection Methods

Create an Attribute:

1. Log in to FireScope SPM.
2. Click on Configuration > CIs > Attributes. The Attributes page displays the Attributes for the selected Configuration Item (in the top left corner).

1. In Navigate or Search for a description, select the CI you want to create the Attribute for.
2. Click on the Create button  (in the top right corner). The Create Attribute page will be displayed.

1. Configuration Item : Attributes are associated with a specific CI. Select a Configuration Item that you want this attribute to be associated with.
2. Description: Enter a descriptive name for this item.
3. Status: This field indicates whether FireScope is actively collecting data for this attribute. Not Supported indicates that there is a problem with the data being collected.
4. Data Collection Settings: This section defines how FireScope should gather values for this attribute, either through the FireScope Agent, SNMP or other means. If you are using FireScope agent please make sure the selected operation is defined in the FireScope Agent’s configuration. For SNMP, you must enter the credentials required to access the SNMP connection (port 161) of the device. The Update interval tells FireScope how often to check values. The Value field allows you to either collect the raw value or its rate of change over time.
   1. Type: This determines how FireScope SPM should gather values for the Attribute. Depending on what you select, additional form fields may appear. 
   2. Operation: Select the operation for gathering data. For e.g. If you are using FireScope agent please make sure the selected operation is defined in the FireScope Agent’s configuration. For SNMP, you must enter the credentials required to access the SNMP connection (port 161) of the device.
   3. Base Units: Select base unit type appended to the end of all values for this Attribute whenever they are displayed. For example, (%) Percent for processor utilization, (B) Bytes for file system size, and (Bps) Bytes Per Second for network performance.
   4. Use multiplier: In case you want to convert the value mathematically before storing, such as converting bits to bytes, select Custom multiplier. Type the number to multiply in the Custom multiplier field.
   5. Type of Information: Format of values that will be returned by this Attribute.
   6. Value: Option to find how much a value has changed since the last time this Attribute was queried. In this case, select Delta (speed per second) or Delta (simple change) to have FireScope SPM only record these values. Select As is to record the actual value.
   7. Update interval (in sec): This field determines how often, in seconds, FireScope SPM should retrieve or listen for new data.E.g. Enter 60 to check every minute, 3600 for once an hour, or 86400 for once a day.
   8. CI Profile Field: Name of a field (default or custom) to update for this CI’s profile section. This feature is useful for selecting certain attributes as asset or CMDB information for a particular CI.
5. Flexible intervals (sec): Use this setting to vary how often you want this data sampled.
6. Attribute Display Options: Other options that will be affect the displaying method the data.
   1. Show value: Is the raw value of this attribute meaningful? If not, FireScope can display an alternative value using this setting.For example, if the possible results of this attribute are either 1 or 0, you can use value translations to display ‘Good’ for 1 and ‘Bad’ for 0.
   2. Item Type: Classify whether or not this attribute impacts the Security, Availability, Performance or Business Impact of the CI this attribute is associated with. Choose all that apply.
      1. Availability
      2. Performance
      3. Security
      4. Key Performance Indicator: Setting this property will enable some summary views of CIs to display the attributes labeled as KPI.
7. Attribute Sets: Attribute Sets are related groups of attributes, such as MySQL performance attributes or Active Directory lookup metrics.
8. Visual Control Display Setting: Use this section to automatically create graphs, gauges and meters based on the value of this attribute.
   1. Show Performance Display:
   2. Display Type:
9. CI Metadata: 
   Options for using metadata.
   1. Asset Name
   2. Type
   3. Detail
   4. SubType
   5. Index
   6. Vendor
   7. Label
10. Tags: Tags are additional identification applied to the main configuration elements: Service Groups, Logical Groups, Configuration Items, Attributes, Event Definitions, Aggregate Event Definitions, Policies, and Visual Controls.Tags are used for search, reports and some specialized displays in the application. System default tags are applied to most agent attributes and some common SNMP (OID) attributes upon creation. You can always create or apply additional tags to any element to further identify each asset.
11. Click on the Save button.

Note: To save time when configuring multiple similar CIs, use a Blueprint.

Edit an Attribute:

1. In the Description column, click on the name of the Attribute you want to edit.
2. If an Attribute is associated with a Blueprint, the Blueprint name precedes the Attribute name and not all fields are editable–such as the operation and type information. If you need to edit an Attribute associated with a Blueprint, select the Blueprint in the Configuration Field (step 3), and edit this Attribute.
3. Edit the form. For more information about the Attribute fields, see Create Attribute.
4. Click on the Save button.

Clone an Attribute:

1. In the Navigation bar, select the appropriate CI and click on the Apply button, Attributes list refreshes for the selected CI.
2. In the Description column, click on the name of the Attribute you want to clone.
3. Edit the form. For more information about the Attribute fields, see Create Attribute.
4. Click on the Save button.      

Delete Attribute

1. In the Navigation bar, select the appropriate CI and click on the Apply button, Attributes list refreshes for the selected CI.
2. In the Description column, check the box next to Attribute name you want to delete.
3. From the drop-down in the bottom right corner of the page, select Delete selected.
4. Click Update. A confirmation window will appears.Note: Deleting an Attribute will have a cascading delete effect. All elements that are based on this Attribute will be effected (for e.g.  Dashboards, AEDs, ED, Policies etc.. Data collected by this Attribute will be lost for good.)

Before You Begin

• Install the FireScope Agent on the asset where the log file is stored.
• Ensure that the FireScope Agent has access to the asset’s file system in order to read the log file.
• Create a CI for the asset. For more information, see Creating a Configuration Item.

Application Logs:

1. Log in to FireScope SPM as a FireScope or Configuration Administrator.
2. Click Configuration > CIs > Attributes. The Attributes page displays the Attributes for the selected CI (in the top right corner).
3. In Configuration Item, select the CI you want to create the Attribute for.
4. Click Create. The Create Attribute page will be displayed.

1. In Description, enter a descriptive name for the log file.
2. In the Data Collection Settings section
   1. In Type, select Agent Remote.
   2. In Operation, type filesystem_logreader(<path to log file>, <optional parameters>). Refer to the table below for an example.
   3. In Type of Information, select Log. 
   4.  Complete the rest of the form. For more information about the Attribute fields, see Creating an Attribute.
   5. Click Save. All log entries for this asset will now be collected, associated with this Attribute, and stored as text-based data.

Example

Windows Event Logs

For Microsoft Windows event logs, the process differs in one way. In Operation, type windows_eventvwr(<name of event log>,<optional filter with regex pattern>).

Log name: application, security, system, Optional Filter: Here are the only valid values for <optional filter>:Type, Source, Category, EventID, Domain, User, Computer, Message. Filters are delimited by pipe ‘|’.Example: windows_eventvwr(system) configures SPM to read the System Event Log.

Example:windows_eventvwr (security,Type:Infomation|Source:Microsoft Windows security|Category:12800|EventID:5156|Domain:firescope|User:N/A|Computer:N/A|Message:Junk) Note: You do not need to know the exact path for event logs.

Once this data is being collected, you can also quickly access the log entries via the search feature.

Creating the TCP Message

To use the DDA, you must send a TCP message via port 8043, with the following tags and variables. The message format will differ depending on the type of DDA you want to use (see the subsequent sections).

There are two types of DDAs:* Incoming – For sending data elements to view, search, and graph in FireScope SPM.

• JSON – For sending associated data elements that will be correlated in FireScope SPM. You can view, search, and graph this data too.

The following sections provide examples of each DDA type.

Incoming

The basic template for an Incoming DDA message is:FSCP_PAYLOAD#<ATTRS><ATTR>CIname,operation,value,timestamp</ATTR></ATTRS>

The following example message illustrates a CI named myCI with an Attribute using the fs_incoming(status) operation:FSCP_PAYLOAD#<ATTRS><ATTR>myCI,fs_incoming(status),”Failed”</ATTR></ATTRS>

Here is the same example as above, plus the time stamp:FSCP_PAYLOAD#<ATTRS><ATTR>myCI,fs_incoming(status),”Failed”,1349297031</ATTR></ATTRS>

To send multiple attributes, use the following examples for guidance.

Example 1

The following Incoming DDA message is formatted to send four separate Attributes at once.FSCP_PAYLOAD#<ATTRS><ATTR>myCI,fs_incoming(A1),12345</ATTR><ATTR>myCI,fs_incoming(A2),753861.001</ATTR><ATTR>myCI,fs_incoming(A3),60812</ATTR><ATTR>myCI,fs_incoming(status),Success,1349297031</ATTR></ATTRS>

Example 2

This example shows another way to format an Incoming DDA message. This message sends two Attributes.

FSCP_PAYLOAD#<ATTRS><ATTR><CINAME>myCI</CINAME><OPERATION>fs_incoming(A1)</OPERATION><VALUE>12345</VALUE><TIMESTAMP>5678</TIMESTAMP></ATTR><ATTR><CINAME>myCI</CINAME><OPERATION>fs_incoming(A2)</OPERATION><VALUE>12345</VALUE><TIMESTAMP>5678</TIMESTAMP></ATTR></ATTRS>

JSON

If you want to send correlated data to FireScope SPM, use the JSON DDA. With JSON formatting, you can send multiple pieces of data from your system and ensure that those pieces of data will be correlated and available for viewing, searching, and graphing in FireScope SPM.

For example, you want to find all the transactions that completed successfully but exceeded your elapsed time threshold. To accomplish this, create a JSON DDA with the following data elements:* Transaction ID

• Status
• Error Code
• Elapsed Time

The following example is a message in JSON format that will send correlated data to FireScope SPM:FSCP_PAYLOAD#<ATTRS>    <ATTR>        <CINAME>myCI</CINAME>        <OPERATION>fs_incoming_json(J1)</OPERATION>        <VALUE>{“transactionid”:11111,”status”:”Success”,”elapsedtime”:10,”errorcode”:400}</VALUE>        <TIMESTAMP>5678</TIMESTAMP>    </ATTR></ATTRS>

Note: You can also format a basic Incoming DDA message in the JSON DDA format.

Attribute

To use the DDA in CIs and Templates, create an Attribute in FireScope SPM and:# In Type, select the Attribute type you are creating from the following options:

1. Attribute Incoming
2. Attribute JSON Incoming

Once the Attribute is populated with data, the Last Value is displayed on the Attributes page. When you click the link in the Last Value column, a pop-up window displays more information.

    Note: You can also create CIs, Logical Groups, and Service Groups, and link CIs to Templates and Groups via FireScope’s REST API.

Event Definition

The following two screen shots show the JSON DDA used in an Event Definition.* Configuration for an Event Definition using the JSON DDA                                                                                                

Visual Controls

Visual Controls are available with data obtained by the DDA just as they are for any data in FireScope SPM.

Reports

You can use the Reports in FireScope SPM to present your data obtained through DDA in an organized, meaningful way.

Group Checked Attribute

Grouped Check Attributes let you group and perform calculations on the same Attribute across multiple Configuration Items (CIs) within a single Logical Group. Multiple functions are supported, including averaging the current attribute value, identifying the maximum or minimum current value, and adding the values together for a group sum. This allows you to define a single event trigger that monitors a metric across multiple CIs, which is especially useful in web farm scenarios. As add or remove CIs from the Logical Group specified, you do not need to modify the Grouped Check Attribute.

Grouped Checks are ideal for scenarios where all CIs in the Logical Group are similar models of hardware, software, and production utilization.

Format

The format for a Grouped Check Attribute is as follows:grouped_operation(group,operation,function,parm)

The following table describes each variable used in the Grouped Check Attribute operation:

Variable

Supported Operations

The following operations are supported with the Grouped Check Attribute:

Supported Functions

The following functions are supported in the Grouped Check Attribute operations:

 Examples

Additional examples of keys for Grouped Check Attributes: * Example 1: Total disk space of Logical Group ‘MySQL Servers’ grouped_sum(“MySQL Servers”,”vfs.fs.size[/,total]”,”last”,”0″)

• Example 2: Average processor load of Logical Group ‘MySQL Servers’ grouped_average(“MySQL Servers”,”system.cpu.load[,avg1]”,”last”,”0″)
• Example 3: Average (5min) number of queries per second for Logical Group ‘MySQL Servers’ grouped_average(“MySQL Servers”,”mysql.qps”,”avg”,”300″)

JMX

JMX is a Java standard for monitoring and managing applications written in the Java development language. JMX supports distributed monitoring and management capabilities and allows access to JMX attributes and operations via a variety of access protocols.

Firescope leverages the access capabilities made available in JMX to deliver the ability to monitor or manipulate many JMX data attributes or operations. In order to deliver these capabilities several configurations must be initiated. The following document is intended to guide you through the necessary configurations required to enable JMX capabilities for use with the FireScope appliance.

Firescope JMX Monitoring Architecture

The figure below details a simple FireScope appliance monitoring two hosts, each of which houses two Java applications.

Configuration Summary The following points highlight the necessary steps required for JMX monitoring with FireScope:* Configure your Java virtual machine (JVM) to allow access to its MbeanServer.

• Use JConsole if necessary to discover deployed Mbean names, attribute names and operation names.
• Create new UserParameters in your remote FireScope agent which will in turn make invocations through the jmxdelegate.jar file to interact with your targeted JMX beans.
• Create items on the FireScope server which reference the newly created UserParameters.

JVM Configuration

Each JVM that will be monitored must be configured to allow access to the JMX server that runs inside of each monitored JVM. Configuration is accomplished by providing a few system parameters to the JVM upon application startup. The parameters are listed below along with their description.

Parameter	Value Type	Example	Description	Required
com.sun.management.jmxremote	None		Instruct the JVM to enable remote JMX access	Yes
com.sun.management.jmxremote.port	Numeric	3900	Server port that JMX server allows access on.	Yes
com.sun.management.jmxremote.authenticate	Boolean	0	Currently authenticated access is not supported.	Yes

Example:/ /java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=3306 -Dcom.sun.management.jmxremote.authenticate=false

Warnings: * Each configured Java virtual machine must use a separate port configuration.

• Configured ports must not conflict with any ports currently in use on the system being configured.
• Use netstat to ensure valid selection of configured ports.
• On Unix / Linux systems use ports > than 1000

Use netstat prior to starting or restarting your application to ensure that the configured port is not in use. Restart your Java application using the new configuration. Then run netstat again to ensure that the system reports a listening port on the selected configuration port.

JMX Discovery

JConsole is a JVM monitoring application that has been in existence since the release of Java JDK 1.5.x. With JConsole it is possible to explore all JMX managed beans in a virtual machine once the JVM is configured to allow JMX remote access as described above. The JConsole executable can be found in the bin directory for your JDK1.5.x or greater installation.

Launch JConsole and select the “Remote Process” option button. Enter “localhost: ” in the entry text box, where the port is the configured JMX listener port. Then select the “Connect” button.

Once started, JConsole will display several tabs. Select the “Mbeans” tab. Along the left hand side is a tree view that lists each deployed Mbean in the JMX Managed Bean Server. The treeview allows exploring down to each Mbean and displays each Mbean attribute or operation. Once you have navigated down to the bean level JConsole will display the Mbean name in the display on the right hand side.

Notes:* JConsole is not required for use with the FireScope monitoring. It is described here for the user’s understanding and for exploring beans deployed to your Mbean server.

• JConsole is part of the JDK download, not the JRE.
• All Mbeans are uniquely identified by name.
• In order to access the attributes or operations of an Mbean you must reference the bean using its unique name.
• In order to maintain uniqueness in names servers such as Tomcat and JBoss, use complex nested names.

Individual JMX Attribute Access

FireScope makes available a client access tool called jmxdelegate for querying and setting individual Mbean attributes and invoking Mbean operations. As described above, the JConsole utility can be used to determine the names and attributes of Mbeans deployed in a particular java virtual machine. The bean names, attributes names and operation names are passed to the jmxdelegate tool for access.

First deploy the jmxdelegate.jar file to an appropriate location on your monitored system. The following example uses a bean names from a system that has a default Tomcat version 6.0.13 deployed running and configured for JMX access.

The jmxclient tool uses the following command format:/java -Dhost= -Dport= -DbeanName= -Dattribute= -Dparameters= -DnestedResult= -jar /jmxdelegate.jar

Parameter	Required	Description
	Yes	Path to the Java VM executable file
	Yes	Host for JMX access. Typically is localhost.
	Yes	Port for JMX access.
	Yes	Name of the managed bean of interest obtained via JConsole.
	No	Name of the manager bean attribute or operation of interest obtained via JConsole.
	No	The attribute or operation parameters if any
	No	The name of a sub-element in a CompositeResult.

The following example command line will retrieve the requestCount? Attribute from the deployed tomcat manager application that comes as a part of the standard Tomcat deployment:

/java -Dhost=localhost -Dport=3306 -DbeanName= Catalina:j2eeType=Servlet,name=HTMLManager,WebModule=//localhost/manager,J2EEApplication=none,J2EEServer=none -Dattribute=requestCount -jar jmxdelegate.jar

Note the nested / complex bean name created by Tomcat shown again as follows:Catalina:j2eeType=Servlet,name=HTMLManager,WebModule=//localhost/manager,J2EEApplication=none,J2EEServer=none

Invoking the above command returns the current requestCount.

Now invoke the manager via a web browser as follows: http://localhost:8080/manager/html

Then re-invoke jmxclient tool to show that the request count increases with each manager invocation.

Example of FireScope JMX Managed Beans

The FireScope solution is delivered with an application called SyslogListener. The SyslogListener application receives syslog messages over TCP/IP and transfers these messages to the FireScope database. The SyslogListener application contains a few managed beans which expose some data points which may be of interest to FireScope users. The exposed beans are described in the following table:

Bean Name	Bean Attribute / Operation	Description
com.firescope.sysloglistener:name=ReceiveMessageCount	PerMinuteMessageCount	Number of messages received during the last minute of operation
com.firescope.sysloglistener:name=ReceiveMessageCount	DailyMessageCount	Cumulative number of messages received since midnight
com.firescope.sysloglistener:name=PersistedMessageCount	PerMinuteMessageCount	Number of messages saved during the last minute of operation
com.firescope.sysloglistener:name=PersistedMessageCount	DailyMessageCount	Cumulative number of messages saved since midnight
com.firescope.sysloglistener:name=MessageExecutionTime	DurationMilliSeconds	Processing time in milli-seconds for the last received message
com.firescope.sysloglistener:name=DatabaseRefresher	ForceDatabaseRefresh	Force all queries to re-issue queries for the next message

Accessing the FireScope managed beans can be accomplished via the following jmxclient invocations:

/java -Dhost=localhost -Dport=3306 -DbeanName=com.firescope.sysloglistener:name=ReceiveMessageCount -Dattribute=PerMinuteMessageCount -jar jmxdelegate.jar /java -Dhost=localhost -Dport=3306 -DbeanName=com.firescope.sysloglistener:name=ReceiveMessageCount -Dattribute=DailyMessageCount -jar jmxdelegate.jar /java -Dhost=localhost -Dport=3306 -DbeanName=com.firescope.sysloglistener:name=PersistedMessageCount -Dattribute=PerMinuteMessageCount -jar jmxdelegate.jar /java -Dhost=localhost -Dport=3306 -DbeanName=com.firescope.sysloglistener:name=PersistedMessageCount -Dattribute=DailyMessageCount -jar jmxdelegate.jar /java -Dhost=localhost -Dport=3306 -DbeanName=com.firescope.sysloglistener:name=MessageExecutionTime -Dattribute=DurationMilliSeconds -jar jmxdelegate.jar /java -Dhost=localhost -Dport=3306 -DbeanName=com.firescope.sysloglistener:name=DatabaseRefresher -Dattribute=ForceDatabaseRefresh -jar jmxdelegate.jar

Note:  The managed beans listed above will not appear or be available until after the SyslogListener has received at least 1 message.

FireScope JMX Agent Configuration

The following list outlines prerequisites for enabling FireScope JMX monitoring on remote hosts:* A valid Java runtime (JRE) must be deployed and available on the remote host

• The jmxdelegate.jar file must be deployed and executable on the remote host.
• UserParameters must be defined and added to the agent configuration file on the remote host.
• The remote agent must be restarted
• It is recommended that the new UserParameter be tested on the remote host

For the purposes of this example we shall assume each of the following has been configured as described below:* A Java VM has already been configured for JMX access on port 4900

• A Java executable exists in the path
• The jmxdelegate.jar file has been deployed to /jars directory
• Our new user parameter shall be called “java.application.monitored.valueâ€?
• Our JMX bean name is called “application.MBeanâ€?
• The property of interest on this Mbean is called “propertyâ€?

To configure our new user parameter we edit the agent configuration file by adding the following line:UserParameter=java.application.monitored.value,java -Dhost=localhost -Dport=4900 -DbeanName=application.MBean -Dattribute=property -jar /jars/jmxdelegate.jar

FireScope JMX Server Configuration

Create a Configuration Item (CI) that references the UserParameter that was created in the previous section. See Creating a Configuration Item.

JMX Enabling Your Own Java Applications

The code listed below describes the steps necessary to make your applications JMX capable. The process covered outlines only standard Mbeans. For more information regarding other typs of Mbeans such as MXBeans, or DynamicBeans refer to the following JMX API documentation or Java tutorial: http://java.sun.com/javase/6/docs/api/.

http://java.sun.com/javase/6/docs/technotes/guides/jmx/tutorial/tutorialTOC.html.

For any class that you wish to make available to JMX you must write an Mbean interface that lists the available JMX methods. The Mbean interface name must have the same prefix name as the implementing class.

public interface ExecutionMessageCounterMBean { public long getPerMinuteMessageCount(); public long getDailyMessageCount(); }

Then provide an implementation for the above interface such as the following:

package example:

import java.util.Calendar; 
public class ExecutionMessageCounter implements ExecutionMessageCounterMBean 
{ 
private int lastIndex; 
private long[] perMinuteMessageCount; 
public ExecutionMessageCounter() 
{ 
super(); 
lastIndex = 0; 
perMinuteMessageCount = new long[1440]; 
} 
public long getPerMinuteMessageCount() 
{ 
int perMinuteMessageCountIndex = getMinuteIndexNow();
return perMinuteMessageCount[perMinuteMessageCountIndex];
} 
public long getDailyMessageCount() 
{ 
long dailyMessageCount = 0; 
for(long oneMinuteCount : perMinuteMessageCount) 
{ dailyMessageCount += oneMinuteCount; }
return dailyMessageCount; }
private synchronized int getMinuteIndexNow() 
{ 
Calendar calendar = Calendar.getInstance(); 
int resultIndex = calendar.get(Calendar.HOUR_OF_DAY) * 60 + calendar.get(Calendar.MINUTE); return resultIndex; 
} 
}

Now register your managed bean with the local Mbean server. Each bean must be registered using a unique name. For purposes of this example we shall use the domain of “example†and a name of “MessageCounter†as shown below:

ExecutioinMessageCounter counter = new ExecutionMessageCounter(); 
MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer(); 
try { ObjectName objectName = new ObjectName(“example:name=MessageCounterâ€); mBeanServer.registerMBean(counter, objectName); } 
catch(Exception exception) 
{ // Add appropriate exception handling }

LDAP Check

Creating an LDAP Check attribute

Note: Before you can create LDAP Check attributes, you should define appropriate credentials to be used to execute the LDAP Queries.

Once you have working LDAP credentials attached to the CI, you can create the LDAP check attributes. Only attributes of CI’s associated to an LDAP credentials will be able to collect LDAP data.# Click on create button on the upper right hand corner of the Attribute page.Note: Make sure appropriate CI is selected.

1. In the Data Collection Settings section select LDAP Check from the Type dropdown list.

1. Click on the Select Operation button and click on LDAP_Check. This will give you the syntax and examples for this attribute.

Operation	Description	Example
(searchDN,ldapAttrName,ldapFilter)return type: CharacterType: LDAP CheckValue returned is attribute dependent	Retrieves information from LDAPParameters:searchDN = LDAP search DN, ldapAttrName = LDAP attribute to be searched, ldapFilter = LDAP search filter	Example: ldap_check(“ou=Users,dc=YourCompany,dc=com”,”mail”,” dn=Bugs Bunny”)

1. When defining the LDAP query ensure that you retrieve information which you can use as an attribute. For e.g. If you wanted to test if any account that begins “SVC-“ is locked out, you could write an LDAP query to simply return true or false, but it may well be more useful to write one which returns a list of those accounts which are locked out. This way, when you add this to a notification, the recipient knows which account(s) to investigate. As an example the following LDAP_Check attribute returns a list of accounts starting “SVC-“ which are currently locked out
   ldap_check(“CN=Users,DC=firescope,DC=com”,”cn”,”(&(cn=SVC-*)(lockoutTime>=1))”)
2. Select appropriate data type returned from the query from Type of Information dropdown list. In the above example it would be character.
3. Set the Update Interval.
4. Click Save.