JFrog Artifactory: Monitoring and Maintenance

Course Duration: 20 minutes

In this course, we will teach you how to maintain your Artifactory instances and their underlying infrastructure in order to keep its services up and running at the desired level of service. We will also list common errors, explore possible causes and provide some ideas on how to track down errors.

As software development and release became a critical part of everybody’s business and Artifactory is likely a critical part of your enterprise automation and CI/CD, we provide these DevOps learning courses to help administrators navigate through the tasks of monitoring and maintenance. We first share with you DevOps best practices in monitoring your environment for any anomalies and suspicious behavior that could indicate an issue.

Finally, this course will help you resolve some of the most common issues JFrog customers experience with Artifactory installation and maintenance. We show you how to use logged errors and error codes provided to your end users, in order to assist you with identifying the root cause for those issues and help you with mitigation techniques that will troubleshoot errors faster and provide you with the necessary information for quick resolution. This course covers the important things an administrator needs to know from common installation errors to common automation errors to the monitoring that can be put in place to detect these errors.

In this course we will cover

• Maintenance tips and tricks for streamlining Artifactory service level
• Monitoring techniques to ensure Artifactory runs smoothly
• Troubleshooting and resolution techniques when Artifactory displays errors

Who should take this DevOps course?

Infrastructure and operations teams who are new to JFrog Artifactory and intend to perform administrative and maintenance tasks related to Artifactory. Anyone who wants to learn DevOps and the ways Artifactory can help with CI/CD and automation can also benefit from this course.

Course Completion

In order to complete the course, you must answer at least 70% of the quiz questions correctly.  

Additional free DevOps learning resources available on JFrog Academy:

JFrog Artifactory: Administration (2020+)
JFrog Artifactory: Infrastructure Package Managers (2020+)
JFrog Artifactory: Development Language Package Managers (2020+)

Let’s take a look at some possible causes for each one. When you are resolving artifacts, a lot of different things can happen. Here are some possible causes. With a 404 error, the message is that the resource was not found, meaning it wasn’t there as expected, not that it doesn’t exist. Sometimes you might have access to the artifacts in a repository, but include and exclude patterns might filter what is included in that repository. And if these include and exclude patterns change after an artifact has been uploaded, the artifact might be present but the new include or exclude patterns prevent it from being resolved. The patterns of a repository are checked before checking to see if the artifact is present. One other possibility is the global security settings in Artifactory. There’s an option to hide the existence of unauthorized resources. 9 If this option is active, then users who don’t have permission to access a resource will get a 404 error instead of a 403. [show screenshot of global settings and highlight the option] A 401 error means that there’s no known user to authenticate. This could happen if no authentication information was provided or if the attempted request was from a user not recognised in the system. Another cause might be that you’re attempting to authenticate  with an authentication service, like LDAP, that was not enabled in Artifactory. It might be that it hasn’t been configured yet, or it hasn’t been activated. [show screenshot of LDAP screen and/or “activate” option]You get a 403 error when you don’t have permission to access a resource. This one is pretty basic. You just need to check your login information or check your permissions. A 409 error occurs when you’re trying to resolve something that doesn’t make sense. A common cause for this error happens with Maven snapshots and releases. If you try to upload a snapshot artifact to a Maven repository not configured to accept snapshots, you'll get a 409. Likewise if you upload a release object to a Maven repository that's configured to accept only snapshots, you will also get a 409. You might also be violating the POM consistency check in a Maven repository.
Another 409 error can happen if there is a checksum mismatch. On archive browsing in case you didn't positively check that archive browsing is enabled you will not be able to browse archives. As by default this feature is turned off.
We’ve given you a few ideas to check when you see one of these resolution areas. Let’s look at some ways you can track down the cause.