Operations guide

Document maturity: DRAFT

Referenced documentation

Introduction

The Artifactory component is part of Software Factory as a Package (SWaaP).

The component is responsible for managing and storing binary artifacts during the software development lifecycle. It allows users to manage dependencies, version control, and access to artifacts efficiently, ensuring smooth integration into CI/CD pipelines. Artifactory supports a wide range of package formats and enables users to maintain reliable artifact repositories across various environments.

Learn more about it .

Service Catalog Items

The catalog items are defined according to the RACI in the LLD.

Grant access to Artifactory

This is performed via the bundle ‘Get Access to Software Factory’ catalog item.

See how to configure User Authentication

Create an Artifactory Permission

We don’t recommend to provide this service to users. Create an Artifactory Project instead.

Using repositories/permissions in the global space removes autonomy to projects It will generate additionnal support requests to platform teams.

Create an Artifactory repository without assignation to a project

We don’t recommend to provide this service to users except for public repository mirroring. To create other type of repositories go to Create a Repository in the Artifactory Project instead.

Using repositories/permissions in the global space removes autonomy to projects It will generate additionnal support requests to platform teams.

Note that the public repository mirrored will be accessible for all project in the Artifactory instance.

To create an public repository mirroring, ask the following information to users:

• Remote repository URL:
  • Tooltip: the url of the public repository
  • Content:
    • Type: single line text
    • Length: [11;255]
    • Value: alphanumerical and special characters -._
    • Regex: ^[a-zA-Z0-9\.-_]{1,64}$
  • Default value: None
  • Example: https://registry-1.docker.io/
• Type of package from the repository:
  • Tooltip: Choose the type of package from the repository: Ex: Docker, Generic …
  • Content:
    • Type: choice list
    • Default value: None
    • Values:
      • Generic
      • Docker
      • Npm
      • Maven
      • PYpi
      • Gradle
      • Go
      • Debian
      • Rpm
      • Swift
      • Terraform
      • Alpine
      • Bowner
      • Cargo
      • Chef
      • CocaPods
      • Conan
      • Conda
      • CRAN
      • Gems
      • GitLfs
      • Helm
      • Ivy
      • NuGet
      • Opkg
      • Composer
      • P2
      • Pub
      • Puppet
      • SBT
      • VCS

Then, create the repository with the following inputs:

• The package type must be selected from the previously obtained informations.
• The project name and project key must be set up. The suggested SF-Doc documentation should be used to determine these.
• Remote repository URL
• Add proper permissions to allow atifactory users to access this repository

How to mirror Artifactory repositories How to managing permissions

Manage an Artifactory permissions through Permission system

We don’t recommend to provide this service to users. Manage users in the Project instead.

Using repositories/permissions in the global space removes autonomy to projects It will generate additionnal support requests to platform teams.

Manage repository permissions through Permission system

We don’t recommend to provide this service to users. Create a Repository in the Artifactory Project instead.

Using repositories/permissions in the global space removes autonomy to projects It will generate additionnal support requests to platform teams.

Create an Artifactory Project

We recommend to allow users to request the creation of an Artifactory project. It will increase user autonomy and reduce the need for platform administrator actions.

⚠️ A user might unintentionally or maliciously request to assign a Repository to their Project. This would provide unauthorized access to its artifacts. See Assign existing repositories to Project to manage it.

To create an Artifactory Project, ask the following information to users:

• Project name:
  • Tooltip: The project name must follow the format <GBU>-<teams>-<project> (this value will also be used as a prefix for the resources created in your project).
  • Content:
    • Type: single line text
    • Length: [1;32]
    • Value: alphanumerical and special characters except |?\<>/"*@]
    • Regex: /^[a-z][^|?\\<>\/"*@\]]{0,31}$/
  • Default value: None
  • Example: tdf-ww-softwarefactory
• Storage quota (GB):
  • Tooltip: amount of GigaBytes needed. Must be multiple of 10. You can increase it later.
  • Content:
    • Type: positive integer
    • Length: [1;1000]
    • Value: at least 10, must be multiple of 10
    • regex: /^(?:[1-9][0-9]{0,2}|1000)$/
  • Default value: 10
  • Example: 540
• Project administrators
  • Tooltip: people that will administrate the Project and its resources
  • Content:
    • Type: list
    • Length: [1;∞]
    • Value: user emails
    • regex: /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/
  • Default value: the email of the requester
  • Example: john.doe@thalesgroup.com,jane.doe@fr.thalesgroup.com
• (optional) Repositories to assign:
  • Type: Group of fields, one group is visible by default, users can add groups of fields
  • Content:
    • Repository type:
      • Tooltip: the type of the repository to assign
      • Conent:
        • Type: choice list
        • Values:
          • Local
          • Remote
          • Virtual
          • Federated
        • Default: Local
    • Repository key:
      • Tooltip: the key of the repository to assign
      • Content:
        • Type: single line text
        • Length: [1;64]
        • Value: alphanumerical and special characters -._
        • Regex: ^[a-zA-Z0-9\.-_]{1,64}$
      • Default value: None
      • Example: my-repo
• (optional) Description:
  • Tooltip: description visible to other Project members
  • Content:
    • Type: multi line text
    • Length: [0;∞]
    • Value: any
    • regex: /.*/
  • Default value: None
  • Example:

A great project description.

It contains several lines and a link to my website: https://example.com

Then, create the project with the following inputs:

• We recommend using the same value for the project name and key to simplify project management.
• Description, Storage Quota: use the information provided above
• Ensure Block Deployment beyond limit is enabled
• Add the project administrators

See how to Create an Artifactory Project

Create a Repository in the Artifactory Project

This action can be performed by a user without needing a platform administrator approval.

See how to Create a Repository in the Artifactory Project

Manage users in the Project

This action can be performed by a user without needing a platform administrator approval.

See how to Manage users in the Project

Assign existing repositories to Project

This action is useful for platforms with repositories created in the global space (not assigned to projects). Users need to assign existing repositories to a Project, during or after a Project creation. If you do a one-time migration to Projects, or start from a fresh instance, you don’t need this.

⚠️ A user might unintentionally or maliciously request to assign a Repository to their Project. This would provide unauthorized access to its artifacts. Follow those verifications before assigning a repository to a Project:

graph TD
    A[Is the repository attached to a permission?]
    A -- Yes --> B[Is the requester the permission manager?]
    B -- Yes --> C[✅ Assign the repo to the Project]
    B -- No --> E[Is there an active permission manager?]
    E -- Yes --> G[⚠️ Permission manager's approval needed]
    A -- No --> D[⚠️ Orphan repo: Security Partner's approval needed]
    E -- No --> D
    D -- Approved --> J[✅ Assign the repo to the Project]
    D -- No SP declared --> F[Hierarchical Manager's approval needed]
    F -- Approved --> J
    F -- Declined --> I[🛑 Decline request]

• Project key:
  • Tooltip: unique key added as a prefix to resources created in your Project.
  • Content:
    • Type: single line text
    • Length: [2;32]
    • Value: lowercase alphanumerical starting with a letter
    • Regex: /^[a-z][a-z0-9]{1,31}$/
  • Default value: None
  • Example: project1
• Repositories to assign:
  • Type: Group of fields, one group is visible by default, users can add groups of fields
  • Content:
    • Repository type:
      • Tooltip: the type of the repository to assign
      • Conent:
        • Type: choice list
        • Values:
          • Local
          • Remote
          • Virtual
          • Federated
        • Default: Local
    • Repository key:
      • Tooltip: the key of the repository to assign
      • Content:
        • Type: single line text
        • Length: [1;64]
        • Value: alphanumerical and special characters -._
        • Regex: ^[a-zA-Z0-9\.-_]{1,64}$
      • Default value: None
      • Example: my-repo
• (optional) Additionnal storage quota (GB):
  • Tooltip: amount of GigaByte to add to the current project quota
  • Content:
    • Type: positive integer
    • Length: [2;∞]
    • Value: must be multiple of 10
    • regex: /^(?:[1-9][0-9]*0)$/
  • Default value: 10
  • Example: 40

See how to Assign existing repositories to the Project

Create a local Artifactory group

We don’t recommend to provide this service to users.

Using local groups prevents users to manage permissions. It will generate additionnal support requests to platform teams.

Add a member to a local Artifactory group

We don’t recommend to provide this service to users.

Using local groups prevents users to manage permissions. It will generate additionnal support requests to platform teams.

Remove a member from a local Artifactory group

We don’t recommend to provide this service to users.

Using local groups prevents users to manage permissions. It will generate additionnal support requests to platform teams.

Consult the list of local Artifactory group members

We don’t recommend to provide this service to users.

Using local groups prevents users to manage permissions. It will generate additionnal support requests to platform teams.

Adding a local Artifactory group to a Permission

We don’t recommend to provide this service to users. Manage users in the Project instead.

Using repositories/permissions in the global space removes autonomy to projects It will generate additionnal support requests to platform teams.

Adding a local Artifactory group to a Project

This action can be performed by a user without needing a platform administrator approval.

See how to Manage users in the Project

Increase Project storage quota

This actions is useful for Projects that need to increase the quota of Artifacts they store. This may come with a price depending on the platform.

• Project key:
  • Tooltip: unique key added as a prefix to resources created in your Project.
  • Content:
    • Type: single line text
    • Length: [2;32]
    • Value: lowercase alphanumerical starting with a letter
    • Regex: /^[a-z][a-z0-9]{1,31}$/
  • Default value: None
  • Example: project1
• Additionnal storage quota (GB):
  • Tooltip: amount of GigaByte to add to the current project quota
  • Content:
    • Type: positive integer
    • Length: [2;∞]
    • Value: must be multiple of 10
    • regex: /^(?:[1-9][0-9]*0)$/
  • Default value: 10
  • Example: 40

See how to Increase Project storage quota

Create a Signing Key for Release Bundles

Release Bundles must be signed to ensure integrity and authenticity.

As an administrator, you are responsible for managing the signing keys used by teams for their Release Bundles.

The official recommendation is to maintain at least one valid, default signing key at the instance level.

While the system permits the creation of multiple keys, this is not currently recommended as a best practice.

You should at least have a default signing Key available.

1. Navigate to Signing Keys Management from Artifactory UI
   1. Administration > Security > Keys Management > Signing Keys
2. Create Add Keys and select the Key Type from the list
   1. Key Alias: <project-name>-release-bundle-key (descriptive name)
   2. Upload private key and public key
   3. Select Add Key

On a User Request

I need to create Release Bundles for my project <project-key-name>. Can you set up a signing key?

Administrator Response:

1. If you want to have only one default key per instance, check if key exists:

   1. If yes, instruct the user to utilize the existing default key.
   2. If no, create a signing key one using the steps above.

2. If you want to manage a key per project:

   1. Create a signing key with descriptive alias like {team-name}-key or {project-key-name}-key
   2. Provide the key alias name to the team

For More information, check the official JFrog Guide to Create a signing key

Billing and onboarding

This section aims at describing how billing related to the component is managed and at specifying offers including access to the component.

Billing & onboarding on TDP

As a component of the SWF product, onboarding and offboarding are managed via Get access to Software Solutions _PostIT tickets, by selecting offername as the offering that includes access to the component.

_Please note that all existing users who have access to the offername offering will automatically have access to this component.

Billing & onboarding on RTDP

_To have access to this component, users should be onboarded to the offer offername.

Billing & onboarding on CASTLE

_To have access to this component, users should be onboarded to the offer offername.

Component deployment and configuration

Requierements & Pre-requisite

All associated ECOL prerequisites are detailed here

Configuration

Setting Helm values

Mandatory Artifactory values are described in the SWaaP Readme - Helm values .

There’s also a list of required and optional ConfigMaps that are needed. These are described in the Artifactory package readme document

Configuring Kubernetes secrets

The required Artifactory secrets and how they are created is described in the SWaaP Readme - Artifactory secrets .

Defaults

Mission Control

Mission Control is enabled by default. The default values are set in the component repo (artifactory.systemYaml , mc ).

Disabling Mission Control or changing the default values is done in the reference repo, in platform values.

Example of disabling Mission Control:

mc:
  enabled: false

Deployment & update procedure

The deployment and update procedures are described in the SWaaP Readme - Quick start section .

Functional Configuration

SAML Configuration

1. Navigate to Administration > Authentication > SAML SSO

2. To add a new provider configuration, click Add Settings complete the following:

   • Check the Enable SAML Integration check box.
   • Provide a name for the specific SAML SSO configuration in Display Name.
   • Provide the SAML Login URL and SAML Logout URL

   ❗Configure the SAML Logout URL to log out users from both your SAML provider and the JFrog Platform at the same time. If you don’t set this field, users stay logged in with the SAML provider even after they log out of the platform. In multi-node environments, set the SAML Logout URL to {baseUrl} to create a dynamic redirect. This ensures that users are redirected back to the specific node they were using after they log out.

   • Fill SAML Service Provider Name field.
     • This should be a URI that is also known as the entityID, providerID, or entity identity.
   • If you enable Using Encrypted Assertion, when set, an X.509 public certificate will be created by Artifactory. You will need to download the X.509 certificate that contains the public key and provide it to your identity provider (IDP).
   • The public key can use either the DSA or RSA algorithms.The Platform uses this key to verify SAML response origin and integrity. Make sure to match the embedded public key in the X.509 certificate with the private key used to sign the SAML response.
   • Select to refresh the X.509 certificate that contains the public key. If you refresh the certificate, this will affect all SAML provider configurations which are enabled for encrypted assertions. You will need to download the updated X.509 certificate that contains the public key and provide it to your identity provider (IDP).

3. Optional settings:

   • Auto Associate Groups When set, in addition to the groups the user is already associated with, they will also be associated with the groups returned in the SAML login response.
   • Auto Create Artifactory Users When set, the system will automatically create new users for those who have logged in using SAML, and assign them to the default groups.
   • Allow Created Users Access To Profile Page When selected, users created after authenticating using SAML, will be able to access their profile. This means they are able to generate their API Key.
   • Auto Redirect Login Link to SAML Login When checked, clicking on the login link will direct the users to the configured SAML login URL.

Provider specific implementation

1. SAML SSO Configuration with Azure
2. SAML SSO Configuration with Google
3. SAML SSO Configuration with Okta
4. SAML SSO Configuration With Keycloak

Cleanup Policies

Cleanup generally refers to removing unnecessary files, applications, and configurations to free up storage and improve system performance. Common tasks include:

• Deleting temporary and cached files
• Clearing old log files
• Uninstalling unused applications
• Deleting old backups

Regular cleanup helps optimize disk space and maintain system efficiency.

Check bellow table with the common actions to manage “Cleanup Policies” via UI and API:

View All Policies

This section outlines how to view all cleanup policies. It guides you in reviewing key details such as the policy status, associated projects with the policy, timestamps for the last and next scheduled runs, last run status, actions performed on each policy, and options for customizing table columns.

• View All Cleanup Policies via UI
• Get all Package Cleanup Policies API
• Get All Release Bundle Cleanup Policies API

Perform a Dry Run

This section outlines how to perform a dry run for a cleanup policy. A dry run lets you preview which items will be deleted based on your defined policy criteria, without performing the actual deleting. This helps you understand the potential outcome before executing the policy. After the dry run, a CSV report is generated, listing all items that would be deleted along with relevant details. Review this list to decide whether to proceed with the policy or adjust the settings.

• Perform Dry Run Cleanup Policy via UI
• Manually Run Package Cleanup Policy API
• Manually Run Release Bundle Cleanup Policy API

Download the Last Run Report

This section outlines how to download the last run report. The report is in CSV format and lists all deleted items with relevant information. You can review the list to learn about the deleted items.

• Download Last Run Report Cleanup Policy
• Download Package Cleanup Policy Run Report API
• Download Release Bundle Cleanup Policy Run Report API

Enable/Disable Policy

This topic outlines how to enable/disable a cleanup policy. By default, newly created cleanup policies are disabled. You must activate a policy before it can execute automatically according to the schedule or be triggered manually.

• Enable/Disable Cleanup Policy
• Enable/Disable a Package Cleanup Policy API
• Enable/Disable Release Bundle Cleanup Policy API

Run Now

This topic outlines how to run a cleanup policy manually. In addition to the periodic automated execution of the cleanup policy that occurs if you enable the policy and set its Cron Expression, you can also manually run the cleanup policy at any time.

• Run Cleanup Policy Manually
• Manually Run Package Cleanup Policy API
• Manually Run Release Bundle Cleanup Policy API

Search Policies

This topic outlines how to search for cleanup policies to locate the desired policy easily.

• Search Cleanup Policy
• Get Single Package Cleanup Policy by Key API
• Get Single Release Bundle Cleanup Policy by Key API

Disable All Policies

This topic outlines how to disable all cleanup policies. As a Platform Admin, you can disable all policies globally, making them inactive. Once this is done, you can activate policies individually as needed.

• Disable All Cleanup Policies
• Disable All Cleanup Policies API

Edit Policy

This topic outlines how to edit a Cleanup policy. After the cleanup policy has been created, you can change the settings or cleanup criteria.

• Edit Cleanup Policy
• Update a Package-Level Cleanup Policy API
• Stop a Running Cleanup Policy API

Stop Policy

This topic outlines how to stop a running cleanup policy. For some reason, you may want to stop a running cleanup policy that is currently running before it finishes completion.

• Stop a Running Cleanup Policy
• Stop a Running Cleanup Policy API

Delete Policy

This topic outlines how to delete a Cleanup policy. If you decide that a cleanup policy is no longer needed, you can delete it.

• Delete Cleanup Policy
• Delete Package Cleanup Policy API
• Delete Release Bundle Cleanup Policy API

Stop All Runs

This topic outlines how to stop all cleanup policy runs. You can perform this action from the policies tab and runs tab. As a Platform Admin, you can stop all currently running policies. Once a policy run is stopped, it cannot resume from its last point. You must restart the policy from the beginning to rerun it.

• Stop All Cleanup Policy Runs
• Stop All Running Cleanup Policies API

Monitoring

This document provides practical guidance for monitoring and logging JFrog Artifactory in Kubernetes, based on JFrog’s official documentation, starting with article related to Monitoring and Logging . It is intended to help teams monitor application health, maintain operational visibility across the Kubernetes clusters, and troubleshoot issues effectively.

In Kubernetes, monitoring JFrog Artifactory is essential to:

• Ensure application availability across pods and workloads
• Optimize performance at container, pod, and node level
• Track resource usage such as CPU, memory, storage, and network activity
• Detect bottlenecks, restarts, and saturation conditions
• Audit user and artifact activity
• Manage storage consumption on persistent volumes
• Prevent outages caused by infrastructure or application pressure
• Support reliable DevOps platform operations

Monitoring and Logging

JFrog Platform offers robust monitoring and logging capabilities that can be integrated into a Kubernetes-based observability strategy.

In Kubernetes deployments, monitoring should cover the following layers:

• Container level

  • CPU and memory consumption
  • Container restarts
  • Application process health

• Pod level

  • Readiness and liveness probe status
  • Restart frequency
  • Log availability
  • Mounted volume access

• Node level

  • Node CPU, memory, disk, and network usage
  • Disk pressure and eviction conditions
  • Kubelet and runtime stability

• Workload level (Deployment or StatefulSet)

  • Ready replicas
  • Unavailable replicas
  • Rollout health
  • Scheduling and scaling behavior

The following official articles provide detailed monitoring information:

• Monitoring Storage
• Monitoring Replication
• Monitoring Service Statuses
• Artifactory JMX MBeans
• Regular Maintenance Operations
• Managing Disk Space Usage

The following official articles provide logging guidance:

• Log Files Location and Naming
• Access Log
• Audit Trail Log
• Live Logs
• Cloud Log Collection
• Open Metrics
• Configuring Log Rotation for Tomcat

Monitor Artifactory Project Usage

Project usage should be monitored regardless of the deployment model, including Kubernetes.

Regularly monitor the number of projects in Artifactory to ensure you remain within the limits of your current Enterprise+ subscription (300 projects by default).

You can retrieve the list of projects using this API:

GET ${baseUrl}/access/api/v1/projects

Transaction Metrics

Transaction metrics represent per-request or per-user-action activity.

In Kubernetes, the most reliable transaction-level sources are still the JFrog application logs generated inside the containers and stored on mounted volumes.

• Request logs (*-request.log) These logs provide a structured record for each HTTP request, including gRPC traffic. They are useful for analyzing:

  • Request timestamp
  • Trace correlation
  • Remote address
  • User agent
  • Username
  • HTTP method
  • Requested endpoint
  • HTTP status code
  • Request and response size
  • Request duration

  These logs are especially valuable for measuring request rate, latency, and error patterns across pods.

More information about this topic can be found in the article about Request Log .

• Access logs Access logs record security-related events such as:

  • Accepted and rejected login attempts
  • Downloads
  • Browsing activity
  • Artifact deployments
  • Source IP and request context

  In Kubernetes, these logs should be collected from the pod log volume and forwarded to a centralized logging platform for correlation across replicas.

  Recommended transaction metrics derived from request and access logs include:

  • Request rate: number of requests per time window
  • Error rate: ratio of failed requests or non-2xx responses
  • Latency: P50, P95, and P99 request duration
  • Top talkers: highest activity by user or source IP
  • Suspicious access attempts: failed logins, denied access, unusual patterns

More information about this topic can be found in the article about Access Log .

Sampled Metrics

Sampled metrics are periodic service and infrastructure metrics collected at regular intervals for dashboards and alerting.

In Kubernetes, these metrics should be combined with cluster-level telemetry such as pod health, node pressure, and persistent volume usage.

Artifactory service metrics endpoint

JFrog documents retrieving metrics for the main Artifactory service using:

curl -H "Authorization: Bearer TOKEN" \
  http://{artifactory_url}/artifactory/api/v1/metrics

In Kubernetes, this endpoint is typically accessed through the Artifactory service inside the cluster or through an ingress, depending on your deployment design.

High-value examples from Artifactory service metrics include:

• Disk and storage

  • app_disk_used_bytes
  • app_disk_free_bytes

• JVM

  • jfrt_runtime_heap_freememory_bytes
  • jfrt_runtime_heap_maxmemory_bytes
  • jfrt_runtime_heap_totalmemory_bytes

• Database

  • jfrt_db_connections_active_total
  • jfrt_db_connections_idle_total
  • jfrt_db_connections_max_active_total
  • jfrt_slow_queries_duration_seconds

• HTTP connection pools

  • jfrt_http_connections_*

• Repositories and storage activity

  • jfrt_repo_by_type_total
  • jfsh_binaries_bytes_download_total
  • jfsh_binaries_upload_failures_total

More information about this topic can be found in the article about Artifactory Service Metrics .

Access service metrics endpoint

JFrog documents retrieving Access metrics using:

curl -H "Authorization: Bearer TOKEN" \
  http://{artifactory_url}/access/api/v1/metrics

These metrics are useful for monitoring authentication, database usage, heap consumption, gRPC activity, and service pressure.

More information can be found in the article about Access Metrics .

Metrics for Supervising Health in Kubernetes

A practical Kubernetes monitoring model should combine application metrics with cluster health indicators.

Recommended health indicators:

• Pod health

  • Restart count
  • Readiness probe failures
  • Liveness probe failures
  • CrashLoopBackOff conditions

• Container resource pressure

  • High CPU usage
  • High memory usage
  • OOMKilled events
  • Throttling due to resource limits

• Node pressure

  • Memory pressure
  • Disk pressure
  • Eviction risk
  • Network saturation

• Persistent volume pressure

  • Low free space on mounted storage
  • Increasing storage consumption
  • Slow I/O affecting repository performance

• Database saturation

  • Active connections approaching maximum
  • Idle connections remaining near zero
  • Slow query duration increasing

• Application memory pressure

  • Low heap free memory
  • Sustained memory drops
  • Increased garbage collection activity

• Service backpressure

  • Increasing queued or pending work
  • Growing gRPC activity
  • Slow response times

• Workload health

  • Unavailable replicas
  • Failed rollouts
  • Scheduling failures caused by resource constraints

More information about these topics can be found in:

• Artifactory Service Metrics
• Access Metrics

Logging

JFrog Artifactory provides standardized logs across its services, which support monitoring, troubleshooting, auditing, and security investigations.

In Kubernetes, logging should be handled as part of the cluster logging architecture rather than as a host-level file management task.

Logging Architecture in Kubernetes

In Kubernetes deployments, there are two main log sources:

1. Container stdout and stderr

   • These are the logs visible through kubectl logs
   • Useful for quick inspection and short-term debugging

2. Application log files

   • JFrog primarily writes structured logs under its internal log directories
   • These logs are more complete and better suited for auditing, request analysis, and operational troubleshooting

Because JFrog uses file-based application logging, Kubernetes administrators should ensure that these log files are written to mounted storage and collected by a log shipping mechanism.

More information about this topic can be found in the article about Log Files Location and Naming .

Key Log Types for Kubernetes Deployments

• Request log (*-request.log)

  • Structured request records for transaction analysis
  • Useful for rate, latency, and error tracking

• Access log (artifactory-access.log)

  • Security-related events such as logins, downloads, browsing, and deployments

• Audit trail log (access-security-audit.log)

  • Changes to users, groups, permissions, and tokens

These logs should be collected from the pod’s mounted log path and forwarded to a centralized logging system.

More information about this topic can be found in the article about governance and compliance .

Best Practices for Logging in Kubernetes

Forward Logs to a Central Logging Platform

Use a Kubernetes-native log collection pattern, such as:

• A DaemonSet-based log collector for cluster-wide collection
• A sidecar container when pod-local parsing or forwarding is required

The collector should:

• Read JFrog application log files from the mounted log directory
• Parse request, access, and audit log formats
• Forward logs to the chosen centralized destination

JFrog also documents its Log Analytics approach for log normalization and forwarding.

More information can be found in the article about Log Analytics .

Do Not Rely Only on kubectl logs

• kubectl logs is useful for fast debugging, but it only exposes container stdout and stderr
• It does not replace structured JFrog application logs used for auditing and detailed analysis

For operational investigations, request, access, and audit logs should be collected from the mounted application log path.

Use Persistent Storage for Log Retention

• Do not depend on ephemeral container storage for important logs.
• Ensure that the JFrog log directory is backed by persistent storage or is continuously harvested by a collector.
• This helps preserve logs across pod restarts, rescheduling, and rolling updates.

Control Log Volume

• Retain high-volume logs such as request logs according to operational need
• Use higher log verbosity only during troubleshooting
• Return to normal logging levels after the investigation is complete

JFrog notes that administrators can temporarily increase logging detail through REST APIs for short-term diagnostics.

Practical Ways to Access Logs in Kubernetes

Use kubectl logs for immediate troubleshooting

Use kubectl logs to inspect what the container writes to stdout and stderr for quick checks, startup failures, and recent errors.

Collect JFrog application logs from mounted volumes

For structured analysis, collect the JFrog log files generated inside the pod from the application log directory mounted into the container.

These include:

• artifactory-service.log
• artifactory-request.log
• artifactory-access.log
• console.log

Use access and audit logs for security and compliance use cases

The following logs are especially important for security reviews:

• Access log for login and artifact activity
• Audit trail log for changes to identities, permissions, and tokens

Forward logs to a central destination

Forward JFrog logs to your centralized logging platform using a Kubernetes log collector.

If syslog is part of your organization’s design, JFrog also documents forwarding logs through syslog-based integrations.

More information can be found in the article about Send Logs to Syslog .

Use Live Logs when enabled

If enabled, JFrog’s Live Logs feature can provide direct access to product logs for troubleshooting.

More information can be found in:

• Live logs
• JFrog Monitoring official article

Official documentation for Monitoring and Logging

• Monitoring and Logging
• Request Log
• Access Log
• Artifactory Service Metrics
• system architecture
• Access Metrics
• Log Files Location and Naming
• governance and compliance
• Log Analytics
• View Log Files from the UI
• Send Logs to Syslog
• Live logs
• JFrog Monitoring official article