Requirements for Publishing Content Packs

When you create and want to publish a content pack, make sure that the content packs meet the basic publishing requirements.

You must check both the content pack requirements and the publishing requirements.

Content Pack Requirements

Content packs must meet some requirements for the content, quality, and standards.

The content requirements include:

• Minimum of three dashboards
• Minimum of one, ideally three, and up to five dashboard filters per dashboard
• Minimum of three dashboard widgets per dashboards
• Maximum of six dashboard widgets per dashboards
• Maximum of three dashboard widgets per row
• Minimum of five alerts
• Minimum of 20 extracted fields

The quality requirements for a content pack are the following:

Alerts

Use meaningful time periods for alerts.

Dashboard groups

• Consider starting with an overview dashboard group.
• Create dashboard groups based on message types (for example, overview or performance), and not on component types (for example, compute, network, or storage).
• Duplicate the same dashboard widget in multiple dashboards groups if the dashboard widget is applicable in each dashboard group.
• Target at least three dashboard groups in a content pack.
• You cannot reorder dashboard groups and dashboard widgets, except with user content.
• When naming dashboard groups, make the title generic and avoid adding product-specific or application-specific names, unless they are used in a component-specific manner.

Dashboard widgets

• Do not put more than three dashboard widgets in the same row.
• When displaying similar information in different formats, ensure that each format brings value.
• Stack-related dashboards together for easier viewing.
• Give the dashboard widgets descriptive names. Do not use field names in widget titles.
• Ensure that each dashboard widget contains information or links about what the chart shows and why it is important. The notes should answer questions such as, “Why is the widget important?” and “Where can additional information be found?”.

Queries

• Every query has at least one full-text keyword and ideally three or more keywords.
• Queries are not based on environment-specific attributes such as source, hostname, or facility.
• Use regular expressions in queries only if keywords and globs are not sufficient. When using regular expressions, provide as many keywords as possible.
• Make queries as specific as possible. Content pack queries should only match events applicable to the product or application for which the content pack was designed.

Field extraction

• Use additional context filters on fields to improve field performance in queries.
• Minimize the number of regular expressions that are used, whenever possible.
• Verify that a regular expression value matches every applicable log message.
• Provide as much pre and post keyword context as possible.
• Every field has at least one full-text keyword and ideally three or more keywords.
• Fields are specific to a product or application and do not return results for other product or application logs.
• Whenever possible, use agents for log collection. Use agents for the parsing of fields instead of field extraction after ingestion.

Field naming

• Use the following naming standard: Prefix_Field_Name. The prefix should be applicable to the content pack.
• Use all lowercase letters.
• Use keywords in the additional context of the field to improve the field performance in queries.

Filters

• When using filters, do not use the match “any” operator unless one or more keywords are defined in the search bar. "any" means that each filter is a separate query. For example, when three filters are used with the "any" operator in a query, the query is treated as three queries. More queries lead to slower results. You can think of "any" as "or" and "all" as the "and" operator.
• When using the text filter with multiple different values, ensure that one or more keywords are defined in the search bar.

Content pack information

• When exporting a content pack, use the naming format Company – Product vVersion. Ideally, the content pack name should be fewer than 30 characters to prevent word wrapping.
• When exporting with a namespace, use the namespace format Ext.Domain.Product.
• When exporting a content pack, export with a detailed description of the product that the content pack addresses and how the content pack helps monitor the product.
• Add information to the Setup Instructions section of a content pack. These instructions help the end user set up and use the content pack.
• Add information in the Upgrade Instructions section of a content pack. These instructions help the end user understand and use all the features in the upgraded version of the content pack.
• Provide detailed information about the tested versions of the product or device for which the content pack is designed.
• By default, it is assumed that content packs are backward compatible for all supported versions of the product or device, and new versions of the content pack will not interrupt with the previous configurations after a content pack update from the Marketplace. If not, ensure that you deliver a separate content pack.
• When separating a content pack, ensure that the content packs have different namespaces and there is no possibility to upgrade from the old to the new content pack. Also, support the use of old and new solutions in parallel, without confusing users with incorrect data or extra alerting. Add exceptions to the Release Notes and Known Issues sections for both content packs.
• Give the content pack a version number in the format Major.Minor.Revision. The major version is for multiple changes in the content pack, for example one or more new dashboards. The minor version is for a small change, such as a bug fix, a widget type change, or the addition of one or two widgets. The revision is optional and can be used by content pack authors when preparing a new version to send to VMware with the revision set, but might be skipped after publishing the finalized version. Use only two-digit version numbers for content packs.

Agent groups

vRealize Log Insight supports both syslog forwarded configurations and its own agents for delivering logs. Content packs designed to be used with agent and agent groups templates include suggested configurations. See the instructions of each content pack for more information.

Publishing Requirements

Before you publish a content pack, check if it meets the publishing requirements. Use the content pack publisher on the Developer Center for content pack recommendations and to upload a version for review to VMware. https://developercenter.vmware.com/web/loginsight

Publishing Requirement	Description
Content Pack file format	A VLCP file.
Events	The appropriate events necessary to validate the content pack.
Overview	A one to two paragraph overview of the content pack.
Highlights	Three highlights, demonstrating the value of the content pack.
Description	A two to three paragraph description of the content pack and its value.
Tech Specs	Describe the minimum system requirements including Product versions and configuration and Log Insight version and configuration. In addition, provide all directions require to configure the product to log to Log Insight and populate the content pack.
Screenshots	Three or more screenshots showing the content pack with real data.
Video (Optional)	Example of how the content pack brings value.
White Paper (Optional)	How to configure the product or application to forwards logs to vRealize Log Insight.