How many rows? How large is the average error? max?
When you say slow to query/slowing the table down, do you mean select queries? Insert queries? Both? You don't have updates, do you?
Do you ever query on LogID? If not, is there any real use for a primary key here? Is the primary key clustered?
A more useful clustered index would probably be on the TS column. You could make clustered PK on TS and then LogID so that it serves queries more usefully and still provides a PK.
Partitioning could improve performance if every query uses the partitioning key (i.e., you only search within the partition period -- which, with so short a range of data, would probably be by month). It could more likely help with maintenance if there really is a lot of data and you use it to archive or truncate partitions for old months.
Proper indexing may solve the problem. Obviously, preventing/fixing the errors is a priority.
But if indexing doesn't solve it, and the volume of errors remains high, you may find that a relational database isn't necessarily the best way to store error logs.