Daily:
The first thing I check each morning when I start work is if any of my backups failed.  
Next I check for any failed SQL jobs on any instance.
Then I check for stuck or long running SSIS jobs.  

Weekly:
I check the server memory utilization.  Under utilized memory is a waste of money and over utilized memory doesn't leave any room for things to run.  You need to find a good balance.
Company specific metrics (largest serial number for example)

Constantly:
blocking and deadlock alerts are generally a good thing to set up.

Randomly:
I check if the backups are restorable.  A backup is only "good" if you know you can restore from it.

We purchased a license for RedGate SQL Monitor and the tool works fairly well.  We have been using it for a number of years and are quite happy with it.  If you have any 3rd party reporting tool available, look at what sort of metrics it collects and what you can report on.  Get a test setup of that tool (if you don't have one already) and play with it.  Fiddle with settings.  Get it to work with your company.

I would also try to find out your RTO and RPO of your comapny and ensure that your backup schedule can meet those.  

And my last tip - make an excel spreadsheet of all of the SQL Instances you are to be in control of.  In that, keep track of the instance name, the Alias (if applicable), the port, the host machine (physical or VM), the failover machine (if applicable), the connection string, the version (such as SQL Server 10.50.4422.0 - Standard Edition (64-bit)).  In the event of disaster recovery, this will work as a nice checklist for you to ensure that everything is back up and working as expected on the appropriate versions.  Plus it makes it handy for the next DBA who comes in to have a quick and easy spreadsheet indicating all the instances that exist.
If possible, it is also nice to have a list of instance purpose (such as having an instance named IntApps and a description of "this is used for internal application data storage") as well as a data owner.  In the event you need to take something offline (updates or upgrades for example) or you need to prune some of the data, it is good to know who you need to contact (person or department).
As a DBA (at least where I work), you are the gatekeeper of the data, not the data owner.  You need to ensure end users can access the data they need to and not access the data they shouldn't be able to see.