user1108631, welcome to SQA. Depending on how the terms are used and who you are talking to, performance tests can be a different beast from stress tests. For brevity, I will only refer to performance tests, but I think my answer is applicable to both.
It is hard to answer your first question without knowing more about the server. If a performance test does nothing else, it needs to measure whether (and how quickly) the server responds under load. Of course it is also important that the responses are correct. In order to keep your test resource requirements within your budget, your performance test may need to accept a lower standard of correctness than your functional tests would. For example, instead of checking everything about a response, you may need to be satisfied that the response contains the expected status code. You may need to experiment to find the right balance between keeping your performance test manageable and detecting the kinds of problems you expect to arise. If the first thing that goes wrong when your server is under load is that it starts returning poorly formed XML/JSON, you may need to check for that. Otherwise, it may not be worth the expense.
Regarding your second question, you can think about two kinds of metrics a performance should capture: capacity metrics and diagnostics. Capacity metrics describe the system's capacity, e.g. number of concurrent users, responses per second, duration between request and response, and so on. (The specifics depend on the service your server provides.) Diagnostics are measurements that help you understand why things go wrong, e.g. memory footprint, number of concurrent database connections, CPU load, and anything else you can think of that's constrained by hardware or by configuration settings.